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だ。このSDKはクラウド環境で広く利用されており、npmのようなパッケージマネージャーを通じてアプリケーションに取り込まれることも多い。
攻撃者がこのSDKを改ざんできれば、開発者や本番システムが自動的に取り込むアップデートを汚染し、通常の依存関係の更新を、悪意のあるコードをひそかに配布する経路へと変えられる可能性があった。
技術的に見ると、Wizは根本原因を、ACTOR_IDパラメーターに関連付けられたAWS CodeBuildのWebhookフィルターにおけるアクセス制御の弱点だと突き止めた。
これらのフィルターは、特に高い権限で実行されるワークフローや機密性の高いシークレットにアクセスできるワークフローにおいて、信頼されたGitHubのIDだけが特権付きビルドをトリガーできるようにするためのものだ。
しかしWizは、これらのフィルターで使われている正規表現がアンカーなしで、厳密な完全一致に必要な「^」^ と「$」$アンカーを欠いていることを発見した。
この点が重要だったのは、アンカーなしのパターンでは意図した範囲を超えて一致する可能性があるためだ。
つまり、ACTOR_IDが承認済みの特定ユーザーIDと一致した場合にのみビルドを許可する代わりに、フィルターは承認済みの文字列を一部に含むGitHubユーザーIDなら、どれでも一致させる可能性があった。
研究者らは、攻撃者がこれを、エクリプス イベントと呼ぶ手法で悪用できることを示した。これは、新たに作成されたより長いGitHubの数値IDに、メンテナーの古い6～7桁の短いIDが部分文字列として含まれるケースだ。
GitHubはIDを連番で割り当て、1日当たりおよそ200,000個の新しいIDを発行しているため、このような重複は実用的に悪用できるほど頻繁に発生するとWizは述べた。標的となったIDでは、エクリプス状態が約5日ごとに発生していたという。
概念実証（PoC）
Wizは、aws/aws-sdk-js-v3を標的とした概念実証で、悪意のあるプルリクエストによって特権付きビルドをトリガーし、ビルド環境内で隠されたペイロードの処理を実行できることを実証した。
その後、ペイロードはプロセスメモリをダンプし、aws-sdk-js-automationアカウントに関連付けられたGitHub Personal Access Token（PAT）を抽出した。これは、2025年のAmazon Qインシデント後に導入された、以前の強化策があったにもかかわらず実行された。
Wizは影響を確認した後、完全なエスカレーションには進まず、2025年8月25日にAWSへ問題を責任ある形で開示した。
研究者らによると、回収されたPATには高い影響力を持つスコープが付与されており、repoおよびadmin:repo_hookが含まれていた。これにより、攻撃者はコラボレーターを招待し、権限を昇格させ、保護されたブランチへ直接プッシュできる可能性があった。
同じトークンは関連する非公開リポジトリへのアクセスも提供しており、潜在的な影響範囲を単一のオープンソースプロジェクトの外側へ広げ、より広範なエコシステムレベルのサプライチェーン侵害につながる条件を作り出していた。
AWSはこの問題に対処し、露出した認証情報をローテーションするとともに、再発を防ぐための追加の保護策を実装した。
CI/CDパイプラインを強化する
CodeBreachのようなサプライチェーンインシデントは、CI/CDにおける小さな信頼の隙間が、いかにして重大な影響をもたらす侵害経路へと急速に発展し得るかを示している。
ビルドシステムが高い権限で実行されている場合、たった1つのバイパスでも自動化に使われる認証情報が露出し、上流での不正なコード変更を可能にする。
目標は、ビルドトリガーへの暗黙の信頼を減らし、信頼されていないワークフローがアクセスできる範囲を制限し、パイプラインの異常な挙動に対する可視性を高めることだ。
- Webhookフィルターの正規表現パターンをアンカーで固定する（^と$を使用する）ことで、IDの完全一致を強制し、アクターIDのバイパスを防ぐ。
- 有効期間が短く、きめ細かい認証情報を使用する（可能な場合はOIDCを使用する）とともに、CI/CDワークフローで広範な長期間有効のPATスコープを避ける。
- プルリクエストに明示的な承認ゲートを設けるとともに、信頼されていないPRのビルドがシークレットや特権変数にアクセスできないようにする。
- 信頼されたリリースパイプラインと信頼されていない貢献ワークフローを分離するとともに、影響範囲を抑えるため、隔離された一時的なランナー上でビルドを実行する。
- 監視するビルドログとランナーのテレメトリーで、異常な実行、メモリのスクレイピング、トークンの不正使用、不正なリポジトリ変更（フック、招待、プッシュなど）を検知する。
- 保護されたブランチによってサプライチェーンの完全性を強化するとともに、必須レビュー、署名付きコミット、アーティファクトの出所情報と署名を導入し、下流のリスクを低減する。
- CI/CDインシデント対応プレイブックをテストし、訓練する（トークンの失効、ランナーの隔離、鍵のローテーション、再ビルド手順など）ことで、自動化の認証情報が侵害された場合に迅速に封じ込められるようにする。
こうした制御は、CI/CDの悪用を防ぎ、自動化に使われる認証情報を保護し、サプライチェーン攻撃の影響範囲を限定するのに役立つ。
ビルド自動化が攻撃経路になるとき
CodeBreachは、サプライチェーンセキュリティが、CI/CDパイプライン内で自動化、ID制御、シークレットが交差する場所に存在する、小さな信頼の前提に左右されることが多いと改めて示している。
顧客への影響が確認されていない場合でも、設定を誤ったビルドゲートによって、通常のプルリクエスト活動がいかに迅速に認証情報の露出や上流の侵害リスクへと変わり得るかを、このシナリオは浮き彫りにしている。
組織はこれをきっかけとして、Webhookのフィルタリングロジックを検証し、トークンの権限を縮小し、信頼されていないビルドを隔離するとともに、エンドツーエンドでリリースの完全性を管理する制御を強化すべきだ。
この、暗黙の信頼を最小化し厳格な検証を徹底するという原則が、組織がゼロトラストソリューションを導入している理由でもある。