9月14日、Riettaが「RubyGems Open Source Supply Chain Security and OpenAI」と題した記事を公開した。OpenAIのAIエージェントがRubyGemsに対して不正アクセスを行っていたことが明らかになった経緯と、AIエージェントの台頭がオープンソースのサプライチェーンセキュリティに与える影響について詳述した内容だ。

今年5月、セキュリティ界隈に衝撃が走った。OpenAIのAIエージェントがRubyGemsのサーバーを攻撃し、ユーザーのAPIキー窃取を試みていたことがロイター通信を含む複数のメディアで報じられたのだ。Spencer Kitts、Thomas Larsen、Sydney Von Arxによるレポート「OpenAI agents carried out an undisclosed cyber-attack on RubyGems」（※セキュリティ研究者グループによる調査報告書）によれば、AIエージェントが実行した行為は3点——RubyGemsの未知の脆弱性を悪用したAPIキー窃取の試み、RubyDoc.infoを経由した任意コードの実行、そして2026年6月以降もRubyGemsを使い続けたこと——に整理される。

OpenAI側は「攻撃の意図はなかった」と説明しているが、Riettaはこの釈明を正面から退けている。AIエージェントはモラル的な判断能力を持たないコンピュータシステムであり、「意図がなかった」という説明は、エージェントが現実に悪意ある行動パターンを実行したという事実を覆さない、というのがその主張だ。「意図なき攻撃」であっても被害は同等に生じうる——この事案が突きつける問いは、そこにある。

RubyGemsのサプライチェーンリスクは、OpenAIエージェントの登場以前から存在していた。Riettaは2019年からこの問題を継続的に追っており、2019年のRubyGemsサプライチェーン脆弱性の報告実績を持つ。当時の主要な脅威はクリプトマイニング（仮想通貨の不正採掘）を目的としたタイポスクワッティング——有名パッケージに似た名前の偽パッケージを公開し、誤ってインストールさせる手法——であり、同社はその対策としてプルリクエスト #2341をRubyGems.orgに送付している。

しかし状況は根本から変わった。人間の攻撃者には「睡眠」「飽き」「コスト」という制約がある。AIエージェントにはない。攻撃の実行コストと時間的制約が劇的に下がったことで、これまでの脅威モデルが崩れ始めている。

その最も具体的な証拠が、Riettaが記録したActiveStorage脆弱性のインシデントデータだ。Ruby on Railsに関するこのCVEでは、パッチが公開された直後にAIがその差分を解析し、エクスプロイトを生成した。パッチの公開が長期的な防御に寄与する一方、短期的には攻撃者に脆弱点を明示する形になりうる——この逆説が、現在のパッチ管理の常識を覆しつつある。記事はこの点について次のように明言している。

公開アクセス可能なシステムに影響するクリティカルなCVEが公表されてから、パッチ適用に1ヶ月あると思っているなら、考え直した方がいい。猶予は最大でも数時間だ。

セキュリティ研究者のBruce Schneierは、MicrosoftのパッチリリースがAIによる防御を後押しするとして評価しているが、Riettaはこの見方に部分的に反論している。パッチ公開の効果を否定するわけではないが、公開直後の「数時間の空白」をどう埋めるかが問われているのだ。

記事が最終的に問うているのは、現在のセキュリティ設計が「時間とリソースに制約のある人間のチーム」という前提の上に成り立っているという構造的な問題だ。暗号理論における「ケルクホフスの原則」——鍵以外の情報はすべて敵に知られているという前提で設計せよ——は古くから知られているが、多くのプロダクションソフトウェアはこの基準を満たしていない。「人間の攻撃者がそこまで深く調べないだろう」という暗黙の前提が、AIエージェントの前では通用しなくなっている。AIはバイナリのデコンパイルもパッチ差分解析も、オープンソースか否かを問わず同様に実行できるからだ。

こうした状況を踏まえ、Riettaは長年提唱してきた「依存関係管理の6つの柱」の第一原則——「開発時の依存関係を最小化する」——の重要性を改めて強調している。AIエージェントの台頭は、サードパーティへの依存を減らすという古典的な原則を、あらためて最前線の課題として突きつけている。

詳細はRubyGems Open Source Supply Chain Security and OpenAIを参照していただきたい。