オープンソースのセキュリティ対応は、これまで「欠陥の詳細をしばらく伏せておけば、その間に利用者へ安全に直せる」という前提で回ってきました。Anil Madhavapeddy氏は、その前提がLLMや自律エージェントの登場で崩れつつある、と書いています。この記事は、OCamlのHTTPライブラリ cohttp のパッチ作業を起点に、公開前でも攻撃の兆候が走り出した現実を示し、OSSメンテナがどう守りを組み替えるべきかを考えるものです。単なる「AIで攻撃が速くなった」という話ではなく、公開・非公開・修正・配布の境界そのものが揺れている、というのが芯にあります。
cohttp の修正公開から十数分で始まった探り著者はその日、OCaml向けの cohttp 6.3.0 に対するセキュリティ修正を出したと説明しています。内容は path traversal、つまり本来たどれないはずのパスにアクセスさせる脆弱性です。普通なら、こうした修正はまず私的に直し、影響を受ける利用者へ伝え、最後に公開アドバイザリを出す流れになります。ところが今回は、PR を開いてからほんの数分で、実運用中の自分のWebサーバーログに、そのバグの典型パターンを試す probe が現れたといいます。
著者はさらに、自分の agent に「この種の path normalisation の問題を調べて」と指示しただけで、攻撃コードに近いものをかなり簡単に作れてしまったと述べます。別の agent は Fable ではセキュリティ制限で断られた一方、DeepSeek V4 Pro は複数の関連問題を見つけたそうです。しかも、まだ公開前の PR を見ただけで、percent-encoded traversal sequences を狙う試行が約10分で飛んできた。著者はこれを見て、攻撃者がパッケージリポジトリを監視しているなら、数秒で踏み込めても不思議ではない、と危機感を強めています。
記事はここから、従来の embargo、つまり脆弱性情報を一定期間伏せるやり方がもう効きにくい、と論じます。背景として、Fang らの研究では、CVE の説明文を与えた GPT-4 agent は15件中87%を悪用できたのに、説明なしでは7%しか成功しなかったと引いています。要するに、攻撃者は詳細なPoCを待たなくても、ざっくりした話題だけで探索を始められる。著者は「mean time to exploit が -7 days」とまで書き、実際にはパッチより先に悪用が始まる局面に入ったのではないか、と見ています。marimo の CVE-2026-39987 は advisory から最初の攻撃試行まで9時間、Langflow の CVE-2026-33017 は20時間だったとも触れ、いまや自動化された exploit 生成が当たり前になりつつある、という見方を示しています。
そのうえで著者は、OSSメンテナの側で何ができるかを三方向で考えます。ひとつは、もっと閉じた場所で修正を進めること。ただし GitHub の temporary private forks は CI が使えず、1つのPRしか入らず、レビューアの追加も面倒で、実運用には向かないと不満を述べます。しかも本当に隠したいのはパッチそのものより、脆弱性の説明を「正しい人だけ」に届けることだ、と言います。
もうひとつは、embargo を前提にせず、公開のまま継続的に出し続けることです。Chrome のように週次で security update を回し、動的パッチで再起動なしに差し替える例を挙げつつ、OSSはライブラリが下流の多数の製品に埋め込まれるので簡単ではないと指摘します。そのためには、どこに使われているかを探る package management、triage を助ける scanning tools、Linux だけでなく OpenBSD や FreeBSD、macOS、RISC-V まで含む品質管理が要る、としています。
最後の方向は、protocol layer で先回りして守ることです。cohttp の今回の修正なら、percent-encoded の path separator を正規化するだけで当面の被害は止められる。著者はこうした “virtual patching” をクラウドでは珍しくないと見ていて、Cloudflare が Log4shell に managed rules を当てた例も挙げます。ただ、OSSにはそれを素早く広く配る仕組みが乏しい。だからこそ、脆弱性を知った瞬間に、各所へ数秒で防御ルールを広げる仕組みが必要だ、と結んでいます。
この記事で印象に残るのは、攻撃側が速くなった、というだけでは終わっていないところです。著者は明確に、守る側のボトルネックが「検出」から「修正の検証と配布」に移ったと見ています。これはかなり厳しい現実だと思います。なぜなら、脆弱性を見つける行為そのものは、LLM の支援でますます安くなる一方で、メンテナが安全な修正だと確認し、リリースし、下流の環境まで届かせる作業は昔からあまり機械化されていないからです。
しかもOSSでは、単一製品を自前で配れる企業と違って、依存関係の先が見えにくい。ライブラリがどこに埋め込まれているかを誰も完全には把握していないなら、公開前の数時間が命取りになるという話は大げさではないでしょう。私が面白いと思うのは、著者が「秘密のまま進める」こと自体より、「誰に説明を届けるか」を問題にし直している点です。守秘の線を引くだけでは、もう十分ではない。そこに違和感がある人ほど、この記事の切迫感を強く受け取るはずです。
GitHub の temporary private forks への不満は、単なるツールの使い勝手の話ではありません。著者が言いたいのは、OSSの開発は本質的に流動的で、レビューもCIも人の出入りも速いのに、脆弱性対応だけを極端に閉じた空間へ押し込むと、普段の開発の流れと噛み合わなくなる、ということだと思います。CI が使えない、複数リポジトリにまたがる修正に弱い、レビューアを一人ずつ管理しなければならない。どれも現場では地味に痛い。
ただ、ここで見逃せないのは、著者が「完全な秘匿」を理想としているわけではないことです。むしろ逆で、漏れて困るのはパッチそのものだけではなく、脆弱性の性質が広く伝わってしまうことだ、と見ています。だから必要なのは、閉じた部屋を作ることより、信頼できる相手にだけ情報を流す運用かもしれない。ここで言う web-of-trust は古風に聞こえますが、現代のOSSでは意外に筋が通っていると思います。公開SlackやDiscordは便利でも漏れやすい。なら、参加者の信頼をどう見極めるかを、もっと技術的に考える必要があるでしょう。
著者の三つ目の提案、つまり protocol layer での proactive protection は、かなり現実的に見えます。cohttp の例なら、今回の本質的な防御は「危ないパス表現を正規化する」ことです。なら、完全な修正版が各所に届く前でも、そのルールだけを先に配れば被害を止められる。クラウド事業者が managed rules で脆弱性を塞ぐのはすでに普通になっていますし、Log4shell のときのように、上流の修正を待たずに守る方法は確かに効果があります。
ただし、ここにはOSSならではの壁があります。CDN のように一箇所で配る立場ではないし、下流の配布経路はバラバラです。だから私は、この提案が実装上いちばん難しい一方で、将来的にはいちばん効く可能性もあると思います。もしライブラリごとに「この種の入力はこう遮断する」という軽量ルールを、信頼できる配布経路で即時に回せるなら、パッチ公開までの数時間に勝てるかもしれない。攻撃者が agent を使って数分で来るなら、守る側も人手だけで勝とうとするのは無理があります。
もう一つ気になったのは、記事が技術論でありながら、かなりメンテナの疲弊を見ていることです。著者は、triage、検証、リリースの能力がフラットなままなのに、機械生成の報告だけが増えている、と感じています。これはセキュリティ問題というより、保守労働の生産性の問題です。大量の自動報告に埋もれれば、本当に危ないものを見抜く時間が削られる。そうなると、攻撃者の自動化以上に、守る側の注意力が先に折れるかもしれません。
その意味で、この記事は「AIが危ない」という単純な警句ではありません。むしろ、AIが脆弱性探索を民主化した結果、OSSの守り方が人間中心の儀式では持たなくなった、と告げています。私はここに、Open Source の弱点と強みが同時に出ていると思います。公開性は探索を早めるが、同時に修正も広げる。だから次に必要なのは、公開をやめることではなく、公開したままでも守れる速度と経路を作ることなのだろう、というのがこの文章の核心だと受け取りました。
参考: Just a rumour of a bug is enough to find a security exploit these days