バグの噂だけで最近はエクスプロイトが見つかる

本日、OCamlのcohttp 6.3.0に対するセキュリティ修正をリリースし、パス・トラバーサル問題を修正しました。パッチ自体は単純なもので、通常の状況であれば、プライベートに修正し、影響を受けるユーザーに通知し、その後公開アドバイザリを発行するという手順を踏むはずでした。しかし今回は、問題修正のためのPR（プルリクエスト）を開いてからわずか数分後に、私のライブウェブサーバーのログに、まさにそのバグパターンを持つプローブ（探索的なアクセス）が観測されました。さらに悪いことに、私は自分のエージェントを使って、バグの概要を知るだけでエクスプロイトを見つけられることに気づきました。つまり、公開パッチが利用可能になるずっと前から悪用できていたのです！セキュリティ問題の噂だけで攻撃者に十分な情報を提供し、新たなエクスプロイトを見つけられるのであれば、オープンソースにおけるセキュリティ対応のあり方を変える必要があります。 1 バグの噂だけで十分な新しいエージェント型エクスプロイトシステム この特定の報告は先週、Jane Street経由でSlackチャンネルにプライベートに届き、それ自体はClaude Fable経由で見つけられたものでした。これはタイムラインを大幅に圧縮します... 1.1 現代のセキュリティレポートのタイムライン パッチの詳細を調べる前に、私は自分のClaudeに影響を受けたコードを調べさせ、他に何が潜んでいるかを確認しました（パス正規化問題の調査を依頼しました）。Fableはセキュリティブロックのため、私がGlasswingにアクセスできないという理由で、残念ながら完全に拒否しましたが、DeepSeek V4 Proはそれに応じ、独立していくつかの関連問題を見つけました。私のエージェントは、ローカルのライブサーバーをプローブするためのエクスプロイトを1分以内に簡単に作成しました。バグ報告者と可能な修正について何度かやり取りした後、私はcohttp#1145を公開し、より多くの目に触れるようにしました。これは通常数日かかり、1〜2週間以内のリリースが合理的です。約10分後（！）、このウェブサイトはパーセントエンコードされたトラバーサルシーケンスに対するプローブを処理しており、自動化された監視システムが公開リポジトリを監視していることを示しています。ローカルでエクスプロイトを作成するのにわずか1分しかかからなかったとすれば、自動攻撃ウィンドウが開始されるまでの10分というのは、実際にはかなり長い時間のように思えます！パッケージリポジトリを監視している意欲的な攻撃者は、数秒以内に簡単に悪用できるでしょう。 1.2 セキュリティエンバーゴはもはや効果がない 従来のセキュリティプロセスでは、バグをエンバーゴ（情報公開の延期）し、詳細の秘密がユーザーを保護すると仮定しています。しかし、今日のエージェントに必要なのは、検索すべき広範な方向性だけであり、それ自体で調査を行うことができます。Fangらの研究によると、CVEの説明を与えられたGPT-4エージェントは、15の脆弱性ベンチマークのうち87%を悪用し、説明なしでは7%でした。2年後、平均エクスプロイト時間は-7日です。つまり、エクスプロイトはパッチに先行するのです！同じ指標は、2018年から2019年には約63日でしたが、2024年にはゼロをクロスしました。簡単な検索で、最近では同様のケースがたくさん見つかります... marimoのCVE-2026-39987は、アドバイザリから最初の攻撃試行まで9時間かかりました。公開されているプルーフ・オブ・コンセプトが存在しない場合でもです。LangflowのCVE-2026-33017は20時間かかりました。私たちは、自動エクスプロイト生成の境目を越えたようです。 2 OSSメンテナーにとってバグ経済学は不利になったのか？ 私の見解では、セキュリティプロセスをある程度反転させる必要があるように思えます。なぜなら、問題クラス（メーリングリストの質問、孤立したブランチの奇妙なコミット、コンテキストリークなど）を検索する一人の人間がいるだけで、他の誰かのエージェントに通知し、エクスプロイトコードを取得させることができるからです。これは驚くべきことです。2026年5月の論文では、「バグ経済学」という用語が造られ、ボトルネックが「防御者の修復スループット」に移行したと論じています。LLMは喜んでエクスプロイトを生成していますが、それらに対する私たちの防御能力は、メンテナーの検証、トリアージ、リリース速度が横ばいのままなので、必ずしも向上していません。これは残念ながら、私のOSSメンテナーとしての視点と一致しています。 問題は、最先端モデル、オープンウェイトモデル、またはプログラム分析のどれが「勝つ」かではありません。問題は、それらをどのようにオーケストレーションして、希少な検証、優先順位付け、およびリリース能力が、機械的な検索やレポート作成ではなく、永続的な修正に向けられるようにするかです。中央の防御機会は、技術的負債の修復です。意味論的に根拠があり、ツールで検証され、モデル支援されたワークフローは、メンテナーがセキュリティ関連の欠陥を、明日の悪用される脆弱性になる前に発見、検証、優先順位付け、修正するのを助けます。-- Demystifying the Mythos or Disrupting Bugonomics?, Pesoli et al, 2026 そして、なぜメンテナーの能力が横ばいのままなのでしょうか？まあ、Mythosのような最先端エージェントへのアクセスがないことは明白な理由の一つですが、回帰を引き起こさないセキュリティパッチのエンジニアリングは、根本的により多くの作業であることも事実です。 3 では、一体どうすればいいのか？ 私たちは明らかにかなり迅速に適応する必要があります。現在の手動トリアージプロセスがなくなるべきだとは思いませんが、Fableが登場して以来、持続不可能な活動の急増を見てきました。流入する火事の水のどれだけが機械生成されているかを把握し始めたばかりですが、明らかにかなりの量です。 Googleのような大企業は、修正が（例えばChromeコードリポジトリで修正されることよりも）ユーザーに直接届くことを優先するために、ソフトウェアにマイクロアップデートを直接組み込んでいます。DockerやOCamlでは、ソフトウェアが使用されるエンドポイントを制御できないため、そのような贅沢はありません。Docker Desktopを除けば、下流のディストリビューションは、独自のタイムラインと条件でOSSを再パッケージ化するのが当然です。OCamlのような小規模プロジェクトでは、最先端モデルへのアクセスを得ること自体が困難です。西洋のモデルにはセキュリティガードが配置されているため、市販のモデルを使用できません。Project Glasswingは、クリティカルインフラオペレーター、クラウドおよび金融プロバイダー、Linux Foundationを含む15カ国150組織に拡大しましたが、「町のパン屋さん」のようなメンテナーはまだアクセスできません。4月にこれが有害かどうかについて私は曖昧でしたが、今日ではかなりひどい結果になっていることは明らかです。 3.1 超極秘のプライベートパッチ開発 最初のリメディエーションは、AIの手の届かない、本当にプライベートな場所で修正を開発することです。GitHubの一時的なプライベートフォークは名目上これを行いますが、私たちにとってはあまりうまくいきません。第一に、GitHubは「脆弱性に関する情報を安全に保つため、CIを含む統合は一時的なプライベートフォークにアクセスできません」と制限しており、これによりメンテナーはCI結果という生命線から切り離されます。第二に、フォークにマージできるPRは1つだけであり、しばしば複数のリポジトリにまたがる問題にはうまく対応できません。また、レビュー担当者は管理者が一人ずつ登録する必要があり、オープンソースの世界ではレビュー担当者は（特に8月には！）誰が利用可能かに応じてドライブバイな存在です。しかし、より広範には、これは間違った漏洩を防ぐものです。パッチを秘密にしておくことは、問題に関する説明が攻撃者に漏洩することなく、まさに適切な人々に届くことを保証することほど重要ではありません。 OSSには、さまざまなエンドツーエンド暗号化されたもの（Matrixを使用しています）だけでなく、非常に漏洩しやすい共有インフラストラクチャ（DiscordやSlack）に分散しているため、堅牢な議論インフラストラクチャがありません。特定のプロジェクトのコンテキストで、善人と悪人を区別するための何らかのウェブ・オブ・トラストが必要です。 3.2 エンバーゴなし、継続的に出荷 もう一つできることは、問題を公開で迅速に修正し、継続的に出荷し、より良い自動化を通じてリリースパスを改善することです。Chromeのような大規模プロジェクトは、週次のセキュリティアップデート、週2回のリリース（！）、および再起動なしでバックグラウンドプロセスを更新されたバイナリと交換する動的パッチングによってこれが可能であることを示しています。これは全く新しい技術ではありません。15年以上前に、ライブksplice LinuxパッチングをXenに統合することを検討しました。Linuxカーネルも可能な限り早く修正を出荷し、最大7日、例外的に14日延期します。しかし、ソフトウェアパッケージングが私たちの主な障害です。