【インフラSE必読】TrivyとKICSが攻撃媒介に：TeamPCPサプライチェーン攻撃の全容と防衛策

DevOps

要約

  • 脅威アクター「TeamPCP」がTrivyコンテナスキャナーとCheckmarx KICSを改ざんし、CI/CDパイプライン経由でAWS/Azure/GCPの認証情報を大量窃取
  • 「セキュリティツールそのものが攻撃の入り口になる」という新しい脅威モデルで、60,000超のクラウドサーバーが被害を受けた
  • GitHub ActionsでTrivyやKICSを使っているなら今すぐバージョン固定とシークレット棚卸しが必要

背景・概要

2026年3月、インフラ・セキュリティの現場に衝撃が走りました。コンテナのセキュリティスキャンに広く使われているTrivy（Aqua Security製）と、IaC（Infrastructure as Code）の脆弱性検査ツールCheckmarx KICSが、脅威アクター「TeamPCP」によって改ざんされていたことが判明したのです。

これは単なるツールの脆弱性ではありません。「セキュリティを高めるために使っているツールが、攻撃の玄関口になる」というサプライチェーン攻撃の典型例です。被害はCiscoのソースコード流出にまで波及し、インフラエンジニアが普段当たり前のように使うツールへの信頼を根本から揺るがす事態となりました。

詳細解説

攻撃の流れ：3月19日〜24日に何が起きたか

TeamPCPの攻撃は段階的かつ巧妙でした。

graph TD
    A[3/19: Trivyのコアスキャナーを改ざん] --> B[trivy-action / setup-trivyも汚染]
    B --> C[3/20: 盗んだnpmトークンでワーム拡散 66+パッケージへ]
    C --> D[3/23: 盗んだCI/CDシークレットでKICSのGitHub Actionを改ざん]
    D --> E[3/24: PyPIのLiteLLMにも波及]
    E --> F[Ciscoのビルドパイプラインに侵入 / 300以上のリポジトリをクローン]

STEP 1: Trivyへの侵入

攻撃者はまずAqua SecurityのTrivyプロジェクトに侵入し、以下の3コンポーネントを改ざんしました。

  • trivy（コアスキャナー）
  • trivy-action（GitHub Actions用）
  • setup-trivy（GitHub Actions用）

改ざんされたバージョンは「TeamPCP Cloud Stealer」と自称するツールを内蔵しており、実行されると以下を収集します。

# 実際の挙動（概念コード）
# Runner.Workerプロセスのメモリダンプ
# SSH秘密鍵の収集
# クラウド認証情報の収集（~/.aws/credentials 等）
# Kubernetesシークレットの列挙
# データベース認証情報の検索

# 収集したデータをAES-256+RSA-4096で暗号化して外部へ送信
tar czf tpcp.tar.gz ~/.aws ~/.kube ~/.ssh
# → 攻撃者のサーバーへexfiltrate

STEP 2: 連鎖的な被害拡大

Trivyから盗んだnpmトークンを使って66以上のnpmパッケージに自己増殖ワーム（CanisterWorm）を仕込み、さらにはKICS・LiteLLM（PyPI）にまで攻撃が広がりました。最終的にCiscoのビルドパイプラインへの侵入に成功し、300以上の内部リポジトリがクローンされています。

なぜGitHub Actionsが狙われるのか

GitHub Actionsのワークフローは、クラウドへのデプロイに必要なシークレット（AWS IAMキー、GCPサービスアカウントキー、Azureの環境変数など）を持っています。外部アクション（uses: aquasecurity/trivy-action@v0.xx）を呼び出すと、その時点でシークレットへのアクセス権が渡されます。

# このような記述が攻撃の入り口になる
- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master  # ← バージョン固定なし = 危険
  with:
    image-ref: myapp:latest
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}  # ← 窃取対象

@master や @latest のような固定されていない参照は、改ざんされたバージョンを即座に取り込んでしまいます。

実務での活用方法（今すぐできる防衛策）

1. GitHub ActionsのアクションをSHAハッシュで固定する

# 悪い例（タグは改ざんされる可能性がある）
uses: aquasecurity/trivy-action@v0.20.0

# 良い例（コミットSHAで固定するとタグ改ざんに強い）
uses: aquasecurity/trivy-action@<コミットSHAをgit ls-remote等で取得して指定>  # 例: a20de54...

2. クラウド認証情報の最小権限化とローテーション

TeamPCPの攻撃で窃取された認証情報の多くが、必要以上に広い権限を持っていました。CI/CD用のIAMロールはReadOnlyまたは特定リソースのみに絞り、定期的にローテーションする運用が必要です。

# AWS IAMポリシーの確認（付与権限の棚卸し）
aws iam list-attached-role-policies --role-name ci-cd-role
aws iam get-policy-version --policy-arn <arn> --version-id v1

3. GitHub ActionsのOIDC認証に移行する

長期的なシークレットを使わず、OIDCトークンで一時的な認証情報を取得する方法が現在のベストプラクティスです。

permissions:
  id-token: write
  contents: read

- name: Configure AWS credentials via OIDC
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
    aws-region: ap-northeast-1

4. 依存関係の監視ツールを導入する

  • Dependabot（GitHub）：外部アクションのバージョン更新を自動でPRにする
  • Socket.dev：npmパッケージへのマルウェア混入をリアルタイム検出
  • Sigstore/Cosign：コンテナイメージの署名検証

まとめ

  • TeamPCPはTrivyとKICSというセキュリティツール自体を攻撃媒介にした前例のないサプライチェーン攻撃
  • GitHub ActionsでサードパーティActionを使っているCI/CDパイプラインはすべて潜在的な標的になりうる
  • 即効性のある対策は外部アクションのSHAハッシュ固定とOIDC認証への移行
  • 長期的にはクラウド認証情報の最小権限化と定期ローテーションが不可欠
  • 「使っているツールが信頼できるか」を継続的に確認する運用体制が、これからのインフラSEには求められる

参考リンク

コメント