これって、AIの問題として再定義されてる古い問題に感じる。人々はすでにカーネルのコミットを比較して、どれがセキュリティ修正かを見極めてたし、LLMが登場するずっと前からやってたよ。パッチが公開されると、レースは基本的に始まってるようなもんだし。短い禁輸期間が本当に役立つかは疑問だな。数時間でパッチできる組織はもう大丈夫だし、他のところはまだ数日や数週間かかる。むしろ、安価なエクスプロイト生成があるから、協調開示がより重要になると思う。

今、セキュリティ修正がたくさん出てるから、コミットを調べるのがずっと魅力的になってる。信号対ノイズ比が高いからね。なんでかっていうと、 > AIが各コミットを通過するたびに評価するのがますます安くて効果的になってるから。これが鍵だね。AIがあれば、「たくさんの変更があるから人は気づかないだろう」っていう仮定が崩れる。

簡単なテストではあまり多くを示さないね。これがセキュリティパッチかどうかをストレートに聞くことで、AIにその仮定に同意するような出力を促してる。混同行列の方がもっと役立つよ。でも、もちろんこれは詳細なAI能力テストのブログじゃないけどね。

AIはアップデートウィンドウを劇的に短縮するよ。2026年は依存関係のクールダウンを考えるには最悪の年だね。むしろ依存関係のウォームアップを考えなきゃ。もうすぐ、オープンソースプロジェクトで脆弱性を開示する安全な方法なんてなくなるだろう。中央集権的なSaaSがここで大きなセキュリティアドバンテージを持つことになるよ。

トニー・ホアの「明らかなバグがないことと、バグがまったくないことの違い」という言葉が、LLMの時代では今まで以上に重要になってるね。

これはずっと前から予測されてたことで、今見えてきた混乱は、誰もLLMが何かを知る前から言われてたことなんだ。きっかけはソフトウェアの透明性へのシフトだね。オープンソースやソースが利用可能なソフトウェアの急激な普及、そしてリバースエンジニアリングやデコンパイルツールの能力の向上が影響してる。普通の市販のクローズドソースソフトウェアが真剣な敵から意味のある形で隠されていたのは、もう10年以上前の話だよ。BinDiff以降、これはスローモーションで進行してきた。脆弱性を開示せずにソフトウェアにパッチを当てることはできないからね。私たちはこのことを否認してきたけど、パッチが脆弱性の開示だと考える専門知識があったから。でもAIがその前提を覆したんだ。今や、何かがメインラインのLinuxにマージされるたびに、いくつかの異なる組織がその差分をLLMのプロンプトに通して、脆弱性を修正しているかどうかを評価し、エクスプロイトのガイダンスを生成している。これは、nginxやOpenSSL、Postgresなどの主要なオープンソースプロジェクトでも、そうなるのは時間の問題だよ。調整された開示の基準は、この環境には合ってない。実際、ここ10年はずっとそうだった。私はこれに対して妙に安心感を持ってるんだけど、調整された開示の基準は常に盲目的で、システム管理者の運用上の都合のために開示を遅らせることが良いことだという前提に基づいているから。そんな前提には疑問を持つ理由があるよ！遅延は、パッチを当てる以外の選択肢を持つシステムオペレーターの手から情報を遠ざけることにもなるしね。

大きな問題があるよ。アメリカは戦争中だし、今、世界の多くの地域がサイバー攻撃レベルで戦争状態にある。アメリカ、EU、中東のほとんど、イスラエル、ロシア… 大規模なサービスが攻撃されて、数日間ダウンしてる - Ubuntu、GitHub、Let's Encrypt、Stryker。病院のシステム全体が部分的にシャットダウンしなきゃならなかった。今、その最中にAIが攻撃を生成するスピードを大幅に上げてしまった。防御側が反応するよりも速くね。ゼロデイ攻撃は以前は稀だったけど、今は普通になってる。状況は良くなる前に悪化するだろうね。もっと悪化するかもしれない。

自動化されたパッチとリリースサイクルが必要だよ。今まで、報告を受けて、調査して、検証して、パッチを当てて、リリースの準備をするのにすごく遅い手作業に頼ってきた。修正をリリースするのに数ヶ月かかることもある。攻撃者が数時間で新しいエクスプロイトを作り出せる時に、これは遅すぎるよ。パッチまでの平均時間を短縮するために、バリューチェーンのボトルネックを改善する必要がある。バグ報告からQAテスト用のパッチ済み製品に1時間で戻せるようにすべきだよ。標準化してオープンソースにして、ソフトウェアサプライチェーン全体で使えるようにしよう（例: Linuxカーネル -> ディストリビューション -> ディストリビューションを使う製品 -> ユーザー）。AIがあるから、これができない理由はないはずなのに、ただ遅いだけなんだ。

これがLog4Shellで実際に起こったことだよ。Day -X + 1: アリババのエンジニアが脆弱性を見つけてApacheに知らせる。パッチがgitにプッシュされて、新しいリリースが調整される。Day -X: ブラックハットがバグを修正するコミットを見つける。攻撃が始まる。Day 0: Minecraftコミュニティでサーバーをクラッシュさせるミームが広がる。特に中国では、pwnされた人たちのログがTwitterで共有される。Day 0 + 約4時間: 友達がTwitterでミームをDMしてくる。CVEを調べたけど、存在しない。友達と一緒にエクスプロイトを再現して、ブログ記事を書くことにした。（別の古いlog4j RCE脆弱性と区別するためにLog4Shellと名付けた）Day ~1: メディアが取り上げ始める。Apacheは反応してパッチを早くリリースせざるを得なくなる。CVEが正式に公開されて、セキュリティスキャナーがそれを特定できるようになる。今日: AIがこれをより早く、一貫して実現させる。パッチは、テスト後に協調的開示が行われ、CVEが公開されるまで非公開にしておくべきかも？ 正しい判断が何かは難しいけど、今後1〜3年でこれが頻繁に起こるだろうね。多くの企業が、AIが攻撃者よりも早くパッチを当てる手助けをするまで、やられ続けることになるだろう。

明らかに解決策は、Linuxがクローズドソースの開発モデルに移行することだよ。セキュリティ研究者は、大手企業（IBMやOracleが信頼できそうだけど、理想的にはマイクロソフトも入れたいね）の委員会に発見を報告すべきだ。そうすれば、その企業がセキュリティパッチを適用して、Linuxのバイナリビルドを顧客に配布することができる。そういう企業とビジネス関係があるユーザーは、すぐに保護されるしね。ソースコードは90日後に教育目的で公開されるし、このアプローチのセキュリティの利点を理解しない人のためにもね。「でも、もし人々を協力させることができたとしても、GPLがそれを法的に不可能にするんじゃない？」って言うかもしれないけど、GPLは最小限の金銭的コストでソースを提供しなきゃいけないと言ってるだけで、時間制限は課してないんだ。伝統的には、ソースコードのリクエストに対してCDを郵送するのが十分なんだよ。アメリカの裁判官が、みんなのセキュリティのためにCDを送るのに短い管理上の遅延があるからって、別の時代のあいまいなライセンス契約に違反してるとは判断しないだろうし、90日なんて司法制度にとっては何でもないからね。