パイプラインが「グリーン」であることと「統制されている」ことは同義ではありません。そして、エージェント型コーディングの普及は、レビュー体制が追いつくよりも速いペースでその差を広げています。
執筆:Shane Warden(ActiveState、プリンシパルアーキテクト)
2026年6月、Novee Securityの研究者らはCordyceps(コーディセプス)と名付けたCI/CD脆弱性の一群を公表しました。同社はnpm、PyPI、crates.io、Goの各エコシステムにまたがる影響度の高いリポジトリ約30,000件をスキャンし、654件にフラグを立て、そのうち300件超を実際に悪用可能であると確認しています。
影響を受けたビルドツールには、Microsoft、 Google、Apache、Cloudflare、Python Software Foundationが公開しているプロジェクトが含まれており、攻撃者に求められる条件は無料のGitHubアカウントだけです。組織メンバーシップも、権限昇格も必要ありません。
これらのパイプラインは、いずれも「グリーン」の状態でした。この脆弱性が存在していた間、スキャナーは正常に動作し、チェックはパスし続け、ダッシュボードにはずっと健全な結果が表示されていました。そもそもスキャナーは、この種の危険を検知できるようには作られていなかったのです。
脆弱性はファイル単体ではなく「組み合わせ」に存在する
GitHub Actionsのワークフローは通常pull_requestによってトリガーされ、これはフォーク元の信頼できないコンテキストで実行され、リポジトリのシークレットにアクセスできず、トークンも読み取り専用です。問題が始まるのはpull_request_targetとworkflow_runで、これらはベースリポジトリのコンテキストで実行されるため、シークレットへのアクセスと読み書き可能なGITHUB_TOKENを持ちます。
攻撃者は、この両方に対して、トリガーとなったプルリクエスト由来の攻撃者制御下のコンテンツを処理させることができます。GitHub Security Labはこれを「pwnリクエスト」と呼んでいます。
被害をもたらす原理は3つあります。コマンドインジェクションは、攻撃者が制御するデータ(ブランチ名、タイトル、コメントなど)をrunステップにそのまま補間し、エスケープされないままシェルコマンド内に紛れ込んで実行されます。actions/github-scriptを通じたコードインジェクションは、攻撃者の入力を実行時にJavaScriptとして評価します。
そしてワークフロー間の権限昇格は、低権限のワークフローに信頼できないデータをアーティファクトや出力として書き込ませ、それを別の高権限ワークフローが読み込んで、メンテナーのトークンを用いて処理してしまうというものです。どちらのワークフローも、単独では悪用できません。
この脆弱性は、これらの要素がどう「接続」されているかによって生まれます。だからこそスキャナーはグリーンのままなのです。SASTやDASTツールは単一ファイルに対してパターンマッチングを行いますが、ここで問題となる個々のファイルは、指示された通りに動作する、正しく整形されたYAMLに過ぎません。
「スキャナーが目にするのは1つのワークフローです。しかし攻撃者が見ているのは、恒久的な認証情報にたどり着く4段階のチェーンなのです」とWarden氏は説明します。
フラグを立てるべき単一の行は存在しません。なぜなら、単一の行に誤りがあるわけではないからです。
これは測定手法の失敗としては最悪のパターンです。赤信号であれば誰かが問題を探しに行きますが、青信号(グリーン)であれば全員がその場を後にしてしまうからです。
プルリクエスト1件で、出荷済みセキュリティコンテンツへの恒久的な書き込み権限を得られる
MicrosoftのAzure Sentinelリポジトリにおいて、Noveeはプルリクエストへのコメント1件で、Microsoft社のCI上で匿名の攻撃者コードを実行し、有効期限のないGitHub Appキーを盗み出せることを実証しました。これはMicrosoft Security Response Centerによって確認されています。
SentinelはMicrosoftのSIEMであり、そのContent Hubは検知ルールと自動化されたPlaybookを顧客のワークスペースに直接配信しています。
ここで盗まれたキーは、数千もの組織が攻撃検知のために依拠しているセキュリティコンテンツへの恒久的な書き込み権限を意味し、それが密かに弱体化された上で、信頼された更新として下流に配信されてしまう可能性があります。
GoogleのAI Agent Development Kitのサンプルリポジトリは、Google Cloud上でエージェントを構築する際に何千人もの開発者がコピーする参照実装です。プルリクエスト1件でGoogleのCI上でコードを実行し、関連するGoogle CloudプロジェクトにおいてOwnerレベルの恒久的なアクセス権限であるroles/ownerにまで権限を昇格させることができました。これはGoogleによって確認されています。
Apache Doriaにも同様の認証情報窃取の経路があり、Apache Security Teamがこれを確認し修正しています。3つの組織、共通するのは1つの「組み合わせ」の問題であり、スキャナーが指し示せるような単一のコード行は存在しません。
誰も「そのプルリクエストを信頼する」と決めたわけではない
エンジニアリング部門のリーダーが立ち止まって考えるべきフレーズは、「誰も監査していない信頼境界」です。誰かが、部外者からの入力をあたかもメンテナーからのものであるかのように扱うワークフローを設定してしまった。しかし、その判断を意図的に下した人間は誰もいません。
このリスクは、一見問題なさそうなコミットが積み重なることで蓄積されていったものであり、AIが生成したワークフローによってさらに増大します。そこでは、判断が下される瞬間そのものが、そもそも監査されないままになっている可能性すらあります。
私自身、AIツールを実運用のエンジニアリング業務に導入し、それがもたらした変化を測定してきた立場として、はっきりと申し上げますが、その活用によるレバレッジは確かに本物であり、私はそれを減速させるべきだと主張しているわけではありません。
しかしNoveeは、エージェント型コーディングこそがこの問題を増幅させる要因であると明言しています。AIツールはCI/CD設定を高速に生成し、同じ安全でないパターンを再生産してしまうため、たった1つのミスが自信満々に、しかも出所を示す手がかりも何もないまま、潜在的に数百万ものリポジトリにわたって複製されてしまうのです。
組織が今取り込んでいるワークフローに関する判断の量は、人間の作業速度を前提に設計されたレビュープロセスの許容量をすでに超えてしまっています。
私たちの標準的なセキュリティ体制も、この状況への備えができていません。CordycepsはCVEではないため、脆弱性の列挙モデルに一切組み込まれることがありません。さらにNISTは2026年4月、すべてのCVEを詳細情報付きで処理しきれなくなったことを認めており、submission件数は2020年比で263%増加しています。リスクは増殖し続けているのです。
幸いにも、Noveeは実際の悪用の証拠を確認しておらず、名前が挙がったベンダー各社はすでに対策強化や修正を行っています。しかし、これは特定の1件の侵害事案ではなく、実証済みで悪用可能な「パターン」であり、業界全体で見ればデフォルト設定のまま未対策となっているケースが大半です。
境界を閉じ、そのうえで境界を越えるものを統制する
直ちに実施すべき対策は数多くあります。信頼できない貢献者からのコンテンツに対してはpull_request_targetよりもpull_requestを優先すること、権限を持つワークフロー内でプルリクエストのHEADコードを絶対にチェックアウトしないこと、イベントデータをインラインで埋め込むのではなくクォート付きの環境変数として渡すこと、権限はデフォルトで読み取り専用にすること、サードパーティ製Actionは可変タグではなくコミットSHAに固定すること、そして初回の貢献者による権限を持つワークフローの実行は手動承認でゲートすることです。
これらをすべて実行すれば、今日の問題は解決できます。しかし、この「問題の類型」そのものは解決されません。次に登場するパターンも、個々には正しく見えるステップの積み重ねから生まれ、それもまたスキャンをパスしてしまうでしょう。AI主導の開発は、このソフトウェアサプライチェーンにおける統制上のギャップを拡大させており、そのスピードは加速しています。
持続可能な対策は、ビルドが何を信頼できるかを「発生源」の段階で統制することです。つまり、パイプラインに取り込まれるコンポーネントやワークフローが、検証可能な来歴を備えた統制済みの出所から供給され、信用ではなくソースからのビルドに基づいていることを担保するのです。
ハイジャックされたアップストリームが汚染されたパッケージを公開した場合、それは取り込みの時点でチェックに引っかかり、失敗しなければなりません。信頼境界は人間が責任を持って管理するものです。そして、その管理体制は、AIが判断を生成するのと同じ速度で機能する必要があります。なぜなら、パイプラインの末端における手作業でのレビューでは、もはや追いつくことができないからです。
Cordycepsは、誰のセキュリティツールも打ち負かしてはいません。個々の部品がすべて設計通りに動作していたからこそ、それらの脇をすり抜けていっただけなのです。これは、測定手法の落とし穴が最も純粋な形で現れた事例です。数値はグリーンのままだったにもかかわらず、それが本来保証すべきはずだったものは、実のところ真実ではなくなっていた、あるいはそもそも一度も真実ではなかったのです。
これらのパイプラインが危険にさらされたのは、スキャナーが機能不全だったからではありません。スキャンをパスすることが、統制されていることを意味しなかったからです。そしてしばらくの間、誰もそのことに気づこうとしなかったのです。
