AIが2つの脆弱性文化を壊しつつある
(jefftk.com)- Copy Fail の公開後、Hyunwoo Kim は既存の修正では不十分だと判断し、同日にパッチを共有したが、Linux式の静かな公開修正手順が外部の発見によって表面化し、エンバゴ終了につながった
- Linux、特にネットワーキング分野では、セキュリティ影響は非公開リストで共有し、バグ修正は公開の場で素早く進めることで、実際の脆弱性の存在は数日間 エンバゴ のまま維持しようとする慣行がある
- 別の人物が公開変更を発見し、セキュリティ影響を把握した後に公開し、その後詳細全文が公開された
- AI がコミットごとのセキュリティ上の意味を評価するコストを下げることで、静かに公開された修正から脆弱性を見つけ出すことが容易になり、シグナル対ノイズ比 も高まっている
- 従来の 90日 の協調開示も弱まりつつあり、今回のケースでは Kim の ESP 脆弱性報告からわずか 9時間 後に Kuan-Ting Chen も独立して報告しており、非常に短いエンバゴの方が望ましい可能性がある
Copy Fail と Linux のセキュリティ修正慣行の衝突
- Copy Fail 脆弱性が公開された後、Hyunwoo Kim は既存の修正では不十分だと判断し、同日にパッチを共有した
- Kim は Linux、特にネットワーキング分野で一般的な手順に従っていた
- セキュリティ影響は Linux セキュリティエンジニアの非公開リストで共有した
- バグ修正は公開の場で静かに、かつ迅速に進めた
- 実際の修正だけが公開された状態で、重大な脆弱性の存在自体は数日間 エンバゴ のまま維持することが目的だった
- 別の人物がその変更を発見し、セキュリティ影響を把握した後、それを公開した
- 脆弱性はすでに公開されたものとみなされ、エンバゴは終了し、その後詳細全文が公開された
AI が2つの脆弱性文化に与える圧力
-
協調開示の文化
- セキュリティバグを発見したらメンテナーに非公開で通知し、通常は 90日 などの期間を与えて修正してもらう方式である
- 目的は、脆弱性が知られる前に修正を先に配布できるようにすることにある
-
「バグはバグ」文化
- Linux で特に一般的なアプローチで、カーネルがしてはならない動作をするなら、誰かがそれを攻撃に転用できるという前提に立つ
- それが脆弱性である事実に注目を集めず、可能な限り早く修正する
- 多くの変更が流れていく状況では、人々が気づかない可能性があり、その間にシステムへパッチを当てる時間が残るという期待がある
-
AI によって公開修正方式のリスクが増大
- この方式はもともと完全には機能していなかったが、AI が脆弱性発見に長けるようになるにつれて、さらに大きな問題になっている
- セキュリティ修正が多く出ることでコミットをレビューすること自体の魅力が増し、シグナル対ノイズ比も高まっている
- AI が各コミットを流し見の段階で評価するコストはますます低下し、効果は高まっている
-
長いエンバゴも弱まる
- 過去には検知速度が遅かったため、ベンダーに報告して 90 日の公開ウィンドウを設ければ、その間に他の人が発見しない可能性が高かった
- いまや AI 支援グループがソフトウェア脆弱性を大量にスキャンしているため、その前提は弱まっている
- 今回のケースでは、Kim が ESP 脆弱性を報告してからわずか 9時間 後に、Kuan-Ting Chen もこれを独立して報告した
- エンバゴは誤った非緊急性を生み、欠陥を修正できる主体を制限して、かえってリスクを高める可能性がある
-
あり得る方向性と簡単なモデルテスト
- 解決策は明確ではないが、非常に短いエンバゴは有力なアプローチに見え、時間とともにさらに短くする必要があるかもしれない
- AI は攻撃者だけでなく防御側も高速化できるため、過去には短すぎて役に立たなかったようなエンバゴも成立可能にするかもしれない
- Gemini 3.1 Pro、ChatGPT-Thinking 5.5、Claude Opus 4.7 に f4c50a403 を与えたところ、3モデルともすぐにセキュリティパッチだと見抜いた
- コミットの文脈なしで diff だけを与えた場合、Gemini はセキュリティ修正だと確信し、GPT はその可能性が高いと見なし、Claude はそうではない可能性が高いと見た
- このテストは
"Without searching, does this look like a security patch?"というプロンプトで各モデルを1回ずつ実行した非常に素早い例であり、モデル間比較に大きな意味を持たせるのは難しい
2件のコメント
非常に短いエンバーゴ vs 長いエンバーゴのどちらかといえば、"非常に短いエンバーゴ" にせざるを得ないので、セキュリティ担当のAIエージェントはさらに忙しくなりそうですね。
Hacker Newsのコメント
この変化はかなり前から予告されていたことで、LLMが何かを知る前から、いま見えている亀裂は予測可能だった
触媒になったのはソフトウェアの透明性の向上だ。オープンソースやソース公開型ソフトウェアの採用は大きく増え、リバースエンジニアリングやデコンパイルツールの性能も大幅に向上した。一般的な既製のクローズドソースソフトウェアが、本気の攻撃者に対して意味のある形で隠されていた時代は、すでに10年以上前に終わっている
BinDiff以降、この問題はゆっくり進行してきた。ソフトウェアをパッチすれば、脆弱性も一緒に公開せざるを得ない。これまでは、パッチがそのまま脆弱性の公開だと見抜くにはある程度の専門性が必要だったため、皆それを否認してきたが、AIがその言い訳を吹き飛ばした
いまでは mainline Linux に何かがマージされるたび、複数の組織がその差分を LLMプロンプト に投入し、それが脆弱性修正かどうかを攻撃的に評価し、エクスプロイトガイドを生成している。nginx、OpenSSL、Postgres のような主要オープンソースプロジェクトの多くも、まもなく同じことになるだろう
協調的な公開慣行はこの環境に適応しておらず、実のところこの10年間ずっと適応していなかったと思う
奇妙なことに、この状況にそれほど不快感はない。というのも、協調的な公開慣行は常に、システム管理者の運用上の都合のために公開を遅らせるのが良い、という前提を無批判に受け入れてきたように見えるからだ。その前提には疑問の余地がある。公開の遅延は、単にパッチを適用する以外の選択肢を持つシステム運用者からも情報を奪う
脆弱性の発見と悪用が容易になるほど、この方式はより一般的になるかもしれない。もちろん常に可能というわけではない
この11年間、ProGuard で難読化したゲームクライアントのバイナリが何度もデコンパイルされて GitHub に上げられたのはかなり腹立たしかった。配布していないサーバーコードだけが非公開のまま残っていた
興味深いことに、ネットワークプロトコルを毎週よりも低い頻度で変更するようになるまでは、攻撃者がそれをリバースエンジニアリングする問題はなかった。いまでは LLM の支援を受ける攻撃者なら、その速度にも追いつけそうだ
これはAIによって新しく生まれた問題というより、古い問題がAI問題として再包装されたものに近いように見える
人々は LLM が登場するずっと前から、カーネルコミットの差分を比較してどれがセキュリティ修正かを見つけていた。パッチが公開で上がった瞬間、競争は事実上すでに始まっている
公開猶予期間を短くすることが本当に役立つのかもよく分からない。数時間でパッチできる組織はすでに問題なく、残りは依然として数日から数週間かかる
むしろ、エクスプロイト生成のコストが下がるほど、協調的公開は重要性を失うのではなく、より重要になる可能性が高い
「公開猶予期間を短くすることが役立つか分からない」については、なぜ90日で、なぜ2年ではないのかが核心だ。同時発見の頻度が高まることで、そのバランスを決めていた要因が変わったというのがこの記事の主張だ。どうせ猶予期間の外にいる複数の人々がエクスプロイトを見つけるなら、猶予期間は実際の窓ではなく幻想にすぎない
「安価なエクスプロイト生成が協調的公開をより重要にする」という点には同意する。ただ同時に、それは実行可能性を下げもする。スクリプトキディですらゼロデイを見つけて悪用できるなら、協調できる能力そのものが崩れる
ホワイトハット文化には常に、ある種の職人ギルド的な倫理があった。そのギルドが壊れれば、その倫理の居場所もなくなる
こういうものは見たことがなく、誇張気味の空気を差し引いても、いまでは LLM のおかげでこうしたことが頻繁に起こりそうな印象を受ける
だから Dirtyfrag が Linux カーネル修正として公開されたのは驚きではない [2]
[1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
[2] https://afflicted.sh/blog/posts/copy-fail-2.html
https://news.ycombinator.com/item?id=47921829
大きな問題が起きている
米国は戦争状態にあり、世界のかなりの地域もいま サイバー攻撃レベルの戦争 をしている。米国、EU、中東の大半、イスラエル、ロシアがそうだ
Ubuntu、GitHub、Let’s Encrypt、Stryker のような主要サービスが攻撃を受けて数日間停止し、病院システム全体が部分的に止まったこともある
そんな中で AI が攻撃生成の速度をはるかに速くした。防御側が対応できる速度より速い。以前はゼロデイ攻撃はまれだったが、いまでは普通のことになった
良くなる前にもっと悪化するし、おそらくずっと悪くなる可能性もある
「いまはセキュリティ修正があまりに多く出るので、コミットを調べる魅力が高まっている。シグナル対ノイズ比が高い」という部分は、なぜそうなるのか疑問だ
「AIが各コミットを通過するたびに評価するコストが、ますます安く効果的になる」という部分が核心だ。AIがあれば、「変更が多すぎるから人は気づかないだろう」という前提が崩れる
この簡単なテストでは多くは分からない。「これはセキュリティパッチか？」と直接尋ねると、AIにその前提を受け入れる出力を出すよう示唆し、誘導してしまう
混同行列 のほうが有用だ。もちろん、この記事が詳細なAI能力テストの記事ではないことは理解している
真陽性、真陰性、偽陽性、偽陰性の数から計算できる
自動化されたパッチとリリースサイクル が必要だ
これまでは、報告を受け、調査し、検証し、パッチし、リリースを準備するという、信じられないほど遅い手動プロセスに依存してきた。修正版を出すのに数か月かかることも珍しくない。攻撃者が数時間で新しいエクスプロイトを量産できる時代には遅すぎる
パッチまでの平均時間を短縮するには、バリューチェーンのボトルネックを繰り返し改善しなければならない
バグ報告を受けてから1時間以内に、QA テスト可能なパッチ済み製品まで持っていけるようにすべきだ。これを標準化またはオープンソース化し、Linux カーネル → ディストリビューション → そのディストリビューションを使う製品 → ユーザーへと至るソフトウェアサプライチェーン全体で使えるようにすべきだ。AIがあるのだから、できない理由はなく、単に我々が遅いだけだ
AIは アップデートウィンドウ を劇的に縮めるだろう。2026年に依存関係のクールダウンを考えているのは最悪で、これからは依存関係のウォームアップを考えるべきだ
近いうちに、オープンソースプロジェクトで脆弱性を安全に公開する方法などというものは消えるだろう。中央集権的な SaaS はここで大きなセキュリティ上の利点を持つ
オープンソース依存関係のリモートコード実行脆弱性は、セキュリティパッチが公開された瞬間に同じように脆弱になるという意味なのだから、なぜ議論になるのか分からない
Tony Hoare の「明白なバグがないこと」と「明白にバグがないこと」に関する古い言葉は、LLM時代 にこれまで以上によく当てはまる
バグをただのバグとして扱うという説明は、個人的にはかなり筋が通らないように読めるが、Linux の世界には実務上の問題より原則を重視する人が多いことは分かっている
それでも 90日 は長く見える
結局のところ、大手AI企業がコアなインターネットインフラに関わる人たちを支援する必要がありそうだ。nginx のようなものに最新・最高のAIを回すのは、私たち全員にとって集団的な利益になると思う
「幸い、AIはここで攻撃者だけでなく防御者も加速できるので、以前なら短すぎて役に立たなかった公開猶予も可能にする」というくだりは、この問題空間の重要な側面だ
セキュリティリスクは最終的に、誰がより多くの トークンコスト を払えるかという軍拡競争に変わるかもしれない
攻撃者はそこにトークンを投入できないが、防御側はソースコードを基に強化作業へトークンを投入できる。攻撃者はブラックボックステストに縛られることになる