グリーンパイプラインはガバナンスが機能しているものではなく、主体的なコーディングによって、レビューで埋められるよりも速いペースでその格差が拡大している。

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つあります。コマンドインジェクションは、攻撃者が制御するデータ（ブランチ名、タイトル、コメントなど）をランステップに直接挿入するため、エスケープされずにシェルコマンド内に取り込まれ、実行されてしまいます。actions/github-scriptを通じたコードインジェクションは、実行時に攻撃者の入力を JavaScript として評価します。

また、ワークフロー間の権限昇格により、低権限のワークフローが信頼できないデータをアーティファクトや出力に書き込むことが可能になり、その後、別の高権限のワークフローがそれを読み取り、メンテナーのトークンを使用して処理を実行します。いずれのワークフローも単独では悪用できません。

この脆弱性は、両者が連携する方法に起因しており、まさにそれがスキャナーが「グリーン」のままとなる理由です。SASTやDASTツールは単一のファイルに対してパターンマッチングを行いますが、ここにある各ファイルは有効で、正しく構成されたYAMLであり、指示されたとおりに動作するからです。

「スキャナーにはワークフローとしてしか見えません。しかし、攻撃者には、永続的な認証情報へとつながる4段階の連鎖が見えるのです」とWarden氏は説明します。

フラグを立てるべき単一の行は存在しません。なぜなら、どの行も間違っていないからです。

これは測定の失敗として最悪のケースです。なぜなら、赤信号なら誰かが問題を探しに行くのに対し、緑信号なら全員が帰宅してしまうからです。

1つのプルリクエストで、リリース済みセキュリティコンテンツへの永続的な書き込みアクセス権を取得

Microsoft の Azure Sentinel リポジトリにおいて、Novee は、プルリクエストへのコメントによって、Microsoft の CI 上で匿名の攻撃者のコードを実行し、有効期限のない GitHub App キーを盗み出すことができることを実証しました。これは Microsoft のセキュリティ対応センター（Security Response Center）によっても確認されています。

SentinelはMicrosoftのSIEMであり、そのContent Hubは検知ルールや自動化されたプレイブックを顧客のワークスペースに直接配信します。

そこでキーが盗まれると、何千もの組織が攻撃の検知に依存しているセキュリティコンテンツへの永続的な書き込みアクセスが可能となり、そのコンテンツは密かに弱体化され、信頼できる更新プログラムとして下流に配信されてしまう。

GoogleのAIエージェント開発キット（AI Agent Development Kit）のサンプルリポジトリは、Google Cloud上でエージェントを構築する際、数千人の開発者が参照するリファレンスです。Googleが確認したように、たった1つのプルリクエストによって、GoogleのCI上でコードが実行され、関連するGoogle Cloudプロジェクトの「roles/owner」権限へ昇格し、永続的な所有者レベルのアクセス権が得られてしまう可能性があります。

Apache Dorisでも同様の経路で認証情報の盗難が発生しており、これはApacheセキュリティチームによって確認され、修正されました。3つの組織、1つの構成上の問題、スキャナーが特定できるようなコードの行は1行もありませんでした。

誰もそのプルリクエストを信頼するよう決定したわけではない

エンジニアリングリーダーが警戒すべきフレーズは、「誰も監査しなかった信頼境界」です。誰かが、外部からの入力をあたかもメンテナーからのものかのように扱うワークフローを設定してしまいました。意図的にその判断を下した人間はいません。

このリスクは、一見妥当に見えるコミットが一つずつ積み重なるにつれて増大し、AIが生成するワークフローでは、意思決定の瞬間がまったく監査されない可能性もあるため、さらに高まります。

私自身、AIツールを本番環境のエンジニアリング業務に導入し、それが何を変えたかを測定してきた。だからこそ、その効果は確かに存在すると明言するし、その導入を遅らせるべきだとは主張しない。

しかし、Noveeは「エージェント型コーディング」こそがリスクを増幅させる要因であると明確に指摘しています。AIツールはCI/CDの設定を迅速に生成しますが、それと同時に同じセキュリティ上の脆弱なパターンも再現してしまうため、たった一つのミスが、出所情報が一切示されず、自信を持って出力された状態で、潜在的に数百万ものリポジトリに波及してしまうのです。

組織が現在処理しているワークフロー上の意思決定の量は、人間の処理速度に合わせたレビュープロセスの処理能力をはるかに上回っています。

従来の標準的なセキュリティシステムも、この状況に対応できていません。「Cordyceps」はCVE（共通脆弱性指標）ではないため、列挙モデルには組み込まれません。さらに、NISTは2026年4月、2020年以降263％増加した報告件数に対応しきれず、すべてのCVEに詳細情報を付加できなくなったことを認めました。リスクは増大の一途をたどっています。

幸いなことに、Noveeは実環境での悪用事例を確認しておらず、名指しされたベンダー各社はセキュリティ強化やパッチ適用を済ませています。しかし、これは単一の具体的な侵害事例ではなく、実証済みの悪用可能なパターンであり、業界全体でデフォルトの状態ではほとんどパッチが適用されていないのが現状です。

境界を閉ざし、それを越えるものを管理する

今すぐ実施すべき対策は以下の通りです：信頼できない貢献については`pull_request_target`ではなく`pull_request` を優先し、特権ワークフロー内でプルリクエストのヘッドコードを決してチェックアウトせず、イベントデータはインライン化せずに引用符で囲んだ環境変数を通じて渡し、権限をデフォルトで読み取り専用に設定し、 サードパーティのアクションを動的なタグではなくコミットのSHAに固定し、初回貢献者に対しては特権ワークフローへのアクセスを手動承認に制限する。

これらすべてを実施すれば、今日の問題は解決されますが、この種の問題そのものは解決されません。次のパターンは、個々に正しい手順を積み重ねて構築され、スキャンにも合格するでしょう。AI主導の開発は、このソフトウェアサプライチェーンのガバナンスのギャップを拡大させており、その勢いは加速しています。

永続的な制御とは、ソースレベルでビルドが何を信頼できるかを管理することです。そうすることで、パイプラインに入るコンポーネントやワークフローは、検証可能な来歴を持つ管理された起源から提供され、単に信頼するのではなく、ソースからビルドされたものとなります。

悪意のあるパッケージを公開する乗っ取られた上流ソースは、取り込みの時点でチェックを受け、そこに失敗しなければなりません。信頼の境界線を管理するのは人間です。その管理は、AIが現在意思決定を生成している速度で機能しなければなりません。なぜなら、パイプラインの末端での手動レビューでは追いつけないからです。

Cordycepsは、誰のセキュリティツールも破ったわけではありません。個々の要素がすべて設計通りに機能していたため、それらをすり抜けてしまったのです。これこそが、最も純粋な形の「測定の罠」です。つまり、本来保証されるべき事柄が（そもそも真実であったとしても）もはや真実でなくなっているにもかかわらず、数値は「グリーン」のままだったのです。

それらのパイプラインが露見したのは、スキャナーが機能しなかったからではありません。スキャンに合格したからといって、それが適切に管理されていたことを意味しなかったからです。しばらくの間、誰も調査しようとしなかったのです。

「緑」のパイプラインは、管理されているパイプラインではありません。あなたのパイプラインを実際に何が流れているのか、確かめてください。

ActiveStateによる提供・執筆。