AWSのビルド自動化におけるサプライチェーン上の弱点により、攻撃者が信頼されたGitHubリポジトリを乗っ取り、広く利用されているAWSソフトウェアコンポーネントに悪意あるコードを押し込めた可能性がありました。
Wizの研究者は、CodeBreachと名付けられたこの問題が、単一のプルリクエストから特権CI/CDワークフローへ至る経路を作り出し、下流のアプリケーションに大規模な影響を及ぼし得たと述べました。
研究者は「…不適切なコードが混入する結果になり得た設定上の問題を、以下のAWS管理のオープンソースGitHubリポジトリにおいて特定した」とし、AWSはアドバイザリで述べています。
さらに「このセキュリティ研究活動の期間中、影響を受けたリポジトリのいずれにも不適切なコードは導入されておらず、これらの活動はAWSの顧客環境に影響を与えず、AWSのサービスやインフラにも影響しなかった」と付け加えました。
CodeBreachのサプライチェーンリスクの内側
Wizは、CodeBreachが4つのAWSリポジトリにまたがるサプライチェーンリスクを露呈させたと報告しました：aws/aws-sdk-js-v3、aws/aws-lc、corretto/amazon-corretto-crypto-provider、およびawslabs/open-data-registry。
懸念は単一プロジェクトに限定されるものではなく、攻撃者が信頼されたCI/CD自動化を悪用して上流に悪意あるコードを注入し、その侵害が通常のビルドやリリースを通じて下流へ連鎖的に波及する可能性がある点でした。
最も深刻な影響シナリオはAWS JavaScript SDKに関するもので、これはクラウド環境全体で広く利用され、npmのようなパッケージマネージャを通じてアプリケーションに取り込まれることが頻繁にあります。
攻撃者がそのSDKを改ざんできれば、開発者や本番システムが自動的に取り込む更新を汚染できる可能性があり、通常の依存関係アップグレードが、悪意あるコードの静かな配布チャネルへと変わり得ます。
技術的には、Wizは根本原因を、ACTOR_IDパラメータに紐づくAWS CodeBuildのWebhookフィルタにおけるアクセス制御の弱点にあると突き止めました。
これらのフィルタは、信頼されたGitHubのIDのみが特権ビルドをトリガーできるようにすることを意図しており、特に昇格権限で実行される、または機密シークレットへアクセスできるワークフローで重要です。
しかしWizは、これらのフィルタで使われていた正規表現がアンカーされておらず、厳密で完全一致のマッチングに必要な^ および$アンカーが欠けていたことを発見しました。
この点が重要なのは、アンカーされていないパターンは意図以上に一致してしまう可能性があるためです。
ACTOR_IDが特定の承認済みユーザーIDに一致する場合にのみビルドを許可するのではなく、承認済みの部分文字列を含む任意のGitHubユーザーIDにも一致し得ました。
研究者は、これを彼らがeclipse events（エクリプス・イベント）と呼ぶ事象を通じて攻撃者が悪用できることを示しました。これは、新たに作成されたより長いGitHubの数値IDが、最終的に古いメンテナの短い6〜7桁のIDを部分文字列として含むケースです。
GitHubはIDを連番で割り当て、1日あたり約20万件の新規IDを発行しているため、Wizは、これらの重なりは実用的な頻度で発生し、対象IDに対するエクリプス条件はおよそ5日ごとに現れると述べました。
概念実証（PoC）
aws/aws-sdk-js-v3を標的とした概念実証で、Wizは悪意あるプルリクエストが特権ビルドをトリガーし、ビルド環境内で隠されたペイロードロジックを実行できることを実証しました。
そのペイロードはプロセスメモリをダンプし、aws-sdk-js-automationアカウントに関連付けられたGitHub Personal Access Token（PAT）を抽出しました。これは、2025年のAmazon Qインシデント後に導入された事前の強化にもかかわらず行われました。
Wizは影響を確認した後、完全な権限昇格には踏み込まず、2025年8月25日にAWSへ責任ある開示を行いました。
研究者は、回収されたPATがrepoやadmin:repo_hookを含む高影響のスコープを持っており、攻撃者がコラボレーターを招待し、権限を昇格させ、保護されたブランチへ直接プッシュできる可能性があると報告しました。
同じトークンは関連するプライベートリポジトリへのアクセスも提供しており、潜在的な影響範囲（blast radius）を単一のオープンソースプロジェクトを超えて拡大し、より広範なエコシステムレベルのサプライチェーン侵害の条件を作り出しました。
AWSはこの問題に対処し、露出した認証情報をローテーションし、再発防止のための追加の安全策を実装しました。
CI/CDパイプラインの強化
CodeBreachのようなサプライチェーンインシデントは、CI/CDにおける小さな信頼の隙間が、いかに迅速に高影響の侵害経路へと変わり得るかを示しています。
ビルドシステムが昇格権限で動作している場合、たった一つの回避でも自動化の認証情報が露出し、上流での不正なコード変更を可能にし得ます。
目的は、ビルドトリガーに対する暗黙の信頼を減らし、信頼できないワークフローがアクセスできる範囲を制限し、異常なパイプライン挙動の可視性を高めることです。
- Webhookフィルタの正規表現パターンをアンカーする（^ と $ を使用）ことで、IDの完全一致を強制し、actor IDのバイパスを防止する。
- 短命で粒度の細かい認証情報を使用する（可能ならOIDC）とともに、CI/CDワークフローで広範かつ長期間有効なPATスコープを避ける。
- プルリクエストに明示的な承認ゲートを要求するとともに、信頼できないPRビルドがシークレットや特権変数へアクセスできないようにする。
- 信頼されたリリースパイプラインを、信頼できないコントリビューションワークフローから分離するとともに、隔離された一時的（エフェメラル）ランナー上でビルドを実行して影響範囲を限定する。
- 監視する：ビルドログとランナーのテレメトリを対象に、異常な実行、メモリスクレイピング、トークンの不正使用、リポジトリの不正変更（例：フック、招待、プッシュ）を検知する。
- 保護ブランチ、必須レビュー、署名付きコミット、成果物の来歴（provenance）/署名により、サプライチェーンの完全性を強化し、下流リスクを低減する。
- CI/CDのインシデント対応プレイブックをテストし、訓練する（例：トークン失効、ランナー隔離、鍵のローテーション、再ビルド手順）ことで、自動化認証情報が侵害された場合に迅速に封じ込められるようにする。
これらの統制は、CI/CDの悪用を防ぎ、自動化認証情報を保護し、サプライチェーン攻撃の影響範囲を限定するのに役立ちます。
ビルド自動化が攻撃経路になるとき
CodeBreachは、サプライチェーンセキュリティがしばしばCI/CDパイプライン内部の小さな信頼前提に左右されることを思い起こさせます。そこでは自動化、ID制御、シークレットが交差します。
顧客への影響が確認されていない場合でも、このシナリオは、設定ミスのあるビルドゲートが、日常的なプルリクエスト活動をいかに迅速に認証情報の露出と上流侵害リスクへ変えてしまうかを浮き彫りにしています。
組織はこれを契機として、Webhookフィルタリングのロジックを検証し、トークン権限を削減し、信頼できないビルドを隔離し、リリースの完全性統制をエンドツーエンドで強化すべきです。
暗黙の信頼を最小化し、厳格な検証を強制するという同じ原則が、組織がゼロトラスト・ソリューションを採用している理由です。
