Trivy 侵害から始まったサプライチェーン攻撃｜CI/CD の防御策と SHA ピン留め

はじめに

2026 年 3 月、オープンソースのコンテナセキュリティスキャナである Trivy の開発環境が侵害され、悪意のあるコードが混入されたバージョンが配布されるという重大なサプライチェーン攻撃（CVE-2026-33634）が発生しました。

最近、npm パッケージや Python パッケージ（LiteLLM）、他のセキュリティツールで相次いで報告されている大規模な侵害事件は、そのいずれもが Trivy インシデントで窃取された CI/CD の認証情報を発端（真の起点）としている可能性が指摘されています。

本記事では、TeamPCP と呼ばれる脅威アクターによる Trivy 侵害のタイムラインと巧妙な手口を客観的に解説し、CI/CD パイプラインを運用するインフラエンジニアが実施を検討すべきバージョンタグの監査と不変のコミット SHA へのピン留めなどの防御策について整理します。

TeamPCP による Trivy 侵害のタイムラインと根本原因

今回のインシデントは、単一の突破口から始まり、初動対応の不備を突いて数週間後に大規模な攻撃へと発展しました。

GitHub Actions 環境の設定ミスによる特権アクセストークンの漏洩

攻撃の起点となったのは 2026 年 2 月下旬です。攻撃者は Trivy の GitHub Actions 環境における設定ミスを悪用し、リポジトリの自動化やリリースプロセスにアクセスできる特権アクセストークンを抽出して、環境内への最初の足場を確立しました。

不完全だった初動の認証情報ローテーションと残留アクセスの悪用

Trivy チームはこの初期侵害を 3 月 1 日に検知し、ただちに認証情報のローテーション（無効化と再発行）を実施しました。しかし、その後の調査で、この初動対応が不十分であったことが判明しています。

参考: Aqua Security Update
“Subsequent investigation revealed the rotation was not fully comprehensive, allowing the threat actor to retain residual access via still-valid credentials.”
（その後の調査で、ローテーションが完全に網羅的なものではなく、脅威アクターがまだ有効な認証情報を介して残留アクセスを維持できていたことが判明しました。）
https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

攻撃者はこの残されたアクセス権を密かに悪用し続け、3 月 19 日に侵害したサービスアカウント（aqua-bot）をトリガーして、悪意のある Trivy バイナリ（v0.69.4）を公式の配信チャネルへ公開しました。

一度漏洩した認証情報は、すべてのトークンとサービスアカウントを網羅的かつ完全に無効化（アトミックなリセット）しない限り、攻撃者に再侵入の隙を与えてしまうという CI/CD セキュリティの厳しさが浮き彫りになっています。

3 月 22 日以降の追加侵害と攻撃の継続

初動のインシデントが収束したと見られていた 3 月 22 日以降にも、攻撃者による活動の継続が確認されています。

Docker Hub イメージ（v0.69.5 / v0.69.6）の追加侵害

Socket および StepSecurity の調査により、Docker Hub で公開されていたaquasec/trivy:0.69.5およびaquasec/trivy:0.69.6のイメージにも、同じ C2 ドメインがバイナリにハードコードされた状態で公開されていたことが確認されました。

参考: Socket – Trivy Under Attack Again

“New image tags (0.69.5 and 0.69.6), along with the previously identified 0.69.4, were found to contain the same infostealer payload, with latest pointing to a malicious image during the exposure window.”

（新しいイメージタグ 0.69.5 と 0.69.6 は、既に確認されていた 0.69.4 と同様に、同じ情報窃取マルウェアのペイロードを含んでおり、露出時間帯には latest タグが悪意のあるイメージを指していました。）

https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise

Aqua Security 内部リポジトリ（aquasec-com 組織）の大規模改ざん

同じく 3 月 22 日には、Aqua Security の内部 GitHub 組織（aquasec-com）に属する 44 の内部リポジトリすべてが、tpcp-docs-プレフィックスにリネームされたうえでパブリック化されるという事態も発生しています。攻撃の経路は、長期有効な Personal Access Token（PAT）を保持していたサービスアカウント（Argon-DevOps-Mgt）の侵害でした。 この事例は、有効期限の長い PAT が単一障害点となり得ることを示す象徴的な出来事です。

並行して発覚した kics-github-action への侵害

3 月 23 日には、Wiz Research によりaquasecurity/kics-github-actionへの並行侵害も確認されました。Trivy だけでなく、Aqua Security が提供する他のセキュリティスキャナー GitHub Actions も影響範囲の確認対象となる点に注意が必要です。

参考: Aqua Security Update

“Also review any workflows referencing aquasecurity/kics-github-action, which was subject to a parallel compromise identified on March 23.”

（3 月 23 日に判明した並行侵害の対象となった aquasecurity/kics-github-action を参照しているワークフローについても確認が推奨されます。）

https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

バージョンタグ（Mutable Tag）書き換えによるパイプラインの乗っ取り

攻撃者は、新しい不審なバージョンを公開するだけでなく、すでに多くのユーザーが利用している既存のバージョンタグを上書きする（Force-push）という極めて巧妙な手法を採用しました。

trivy-action のバージョンタグ強制上書きによる悪意あるコードの注入

aquasecurity/trivy-actionリポジトリにある 77 個のバージョンタグのうち、イミュータブル（不変）なリリースとして保護されていた v0.35.0 を除く 76 個のタグすべてが、悪意のあるコミットへ強制的に書き換えられました。さらにaquasecurity/setup-trivyについても、7 個すべてのタグが同様に書き換えられています。

参考: Aqua Security Update
“By modifying existing version tags associated with trivy-action, they injected malicious code into workflows that organizations were already running. Because many CI/CD pipelines rely on version tags rather than pinned commits, these pipelines continued to execute without any indication that the underlying code had changed.”
（trivy-action に関連付けられた既存のバージョンタグを変更することで、組織がすでに実行しているワークフローに悪意のあるコードを挿入しました。多くの CI/CD パイプラインは固定されたコミットではなくバージョンタグに依存しているため、これらのパイプラインは基礎となるコードが変更されたことを示すことなく実行され続けました。）
https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

CI/CD パイプラインの設定ファイル（YAML）で@v0.28.0などの動的なタグ（Mutable Tag）を指定していた組織は、設定を一切変更していないにもかかわらず、裏側で密かに悪意のあるコードを実行させられる状態に陥りました。

なお、Socket 社が 100 stars 以上の 767 リポジトリを対象に実施した解析によると、そのうち 45 リポジトリで侵害期間中に悪意あるバージョンのアクションが実行されていたことが確認されています。公開リポジトリだけでもこの規模であり、プライベートリポジトリを含めた実被害はさらに大きいと見られます。

侵害版が配布されていた具体的な時間枠

Aqua Security が公開した公式アドバイザリ（GHSA-69fq-xp46-6×23）では、各コンポーネントの露出時間枠が明示されています。自組織の監査を行う際は、以下の時間枠内で該当アクションが実行されていないかを確認することが推奨されます。

参考: GitHub Security Advisory GHSA-69fq-xp46-6×23

https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6×23

スキャン実行前にシークレットを窃取するサイレントなデータ持ち出し

さらに厄介なことに、パイプライン上で実行された悪意のあるペイロードは、正規の Trivy スキャン処理が開始される前に動作するように設計されていました。

そのため、AWS や GCP などのクラウド認証情報、GitHub トークン、Kubernetes トークンといった環境変数内のシークレットを、タイポスクワットドメインであるscan.aquasecurtiy[.]org（IP: 45.148.10.212）へ密かに送信しながらも、表面上のセキュリティスキャン自体はエラーを出さずに正常終了しているように見せかけていました。

また、フォールバック機構として、盗んだ PAT を使って被害者自身の GitHub 組織内にtpcp-docsという名前のパブリックリポジトリを作成し、そこへ暗号化された認証情報をリリースアセットとしてアップロードする手法も確認されています。

参考: CrowdStrike – From Scanner to Stealer

“If the endpoint returns a non-2XX response and INPUT_GITHUB_PAT is available, the script falls back to exfiltrating through GitHub itself. It will create a public repository named tpcp-docs under the victim’s GitHub account, create a timestamped release, and upload the encrypted bundle as a release asset.”

（エンドポイントが 2XX 以外のレスポンスを返し、INPUT_GITHUB_PAT が利用可能な場合、スクリプトは GitHub 自体を介した流出経路にフォールバックします。被害者の GitHub アカウント配下に tpcp-docs という名前のパブリックリポジトリを作成し、タイムスタンプ付きのリリースを作成して、暗号化されたバンドルをリリースアセットとしてアップロードします。）

https://www.crowdstrike.com/en-us/blog/from-scanner-to-stealer-inside-the-trivy-action-supply-chain-compromise/

窃取された NPM トークン等によるエコシステム全体への波及

この単一のオープンソースプロジェクトの侵害は、結果として世界中のソフトウェアサプライチェーン全体を揺るがす事態に発展しました。

商用環境（Aqua Platform）への影響とオープンソース版の被害状況

まず前提として、開発元である Aqua Security が提供する商用製品（Aqua Platform）は、オープンソース環境からアーキテクチャ的に完全に分離されており、今回のインシデントの影響を受けていません。

参考: Aqua Security Update
“There is no indication that Aqua Security’s commercial products were impacted by this incident, including Trivy as delivered within the Aqua Platform.”
（Aqua Platform 内で提供される Trivy を含め、Aqua Security の商用製品がこのインシデントの影響を受けたという兆候はありません。）
https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

被害を受けたのは、GitHub Actions や Docker Hub 等を通じて、オープンソース版の Trivy コンポーネントを直接パイプラインに組み込んでいた世界中の組織です。

単一の侵害から NPM エコシステムなどへの二次的・三次的な攻撃展開

今回の攻撃の最大の脅威は、Trivy を踏み台にして窃取された膨大な数の認証情報が、即座に次の攻撃（兵器化）へ転用された点にあります。

公式アップデートにおいても、Trivy の実行環境から盗まれた NPM のパブリッシュトークンが積極的に悪用され、NPM エコシステム全体にマルウェアを伝播させていることが強く警告されています。 また、この一連のトークン群を利用して、Python パッケージである litellm へのバックドア混入 や、litellm Proxy の SQL インジェクション脆弱性 CVE-2026-42208 など、後続の攻撃へと連鎖的に発展しており、CI/CD パイプラインの単一障害点がエコシステム全体のセキュリティ崩壊を招く危険性を実証する結果となりました。

現場で直ちに実施すべき影響調査の具体手順

Trivy 関連コンポーネントを CI/CD パイプラインに組み込んでいる組織は、まず「自社環境が侵害時間枠に該当する実行履歴を持つか」を特定することから始めることが推奨されます。ここでは GitHub CLI（gh）を用いた実践的な調査コマンドを紹介します。

GitHub CLI による影響ワークフローの洗い出し

組織内のリポジトリでtrivy-actionまたはsetup-trivyを参照しているワークフローを確認します。

# 組織全体で trivy-action を参照しているワークフローを検索
gh search code "aquasecurity/trivy-action" --owner <YOUR_ORG> --extension yml

# setup-trivy も同様に確認
gh search code "aquasecurity/setup-trivy" --owner <YOUR_ORG> --extension yml

# kics-github-action（並行侵害が確認されたため要確認）
gh search code "aquasecurity/kics-github-action" --owner <YOUR_ORG> --extension yml

検索でヒットしたリポジトリについて、3 月 19 日から 20 日にかけてのワークフロー実行履歴を確認します。

# 特定リポジトリの 3/19-20 のワークフロー実行履歴を取得
gh run list --repo <OWNER>/<REPO> --created "2026-03-19..2026-03-20" --json conclusion,createdAt,name,url

参考: GitHub CLI 公式リファレンス（gh run list）

https://cli.github.com/manual/gh_run_list

フォールバック流出経路（tpcp-docs リポジトリ）の有無確認

攻撃スクリプトは、C2 サーバーへの送信に失敗した場合のフォールバックとして、被害者の GitHub 組織内にtpcp-docsという名前のパブリックリポジトリを作成します。このリポジトリが存在すれば、認証情報が実際に流出した可能性が高いと判断できます。

# 組織アカウント配下の確認
gh repo list  --limit 1000 --json name \
  --jq '.[] | select(.name | contains("tpcp-docs"))'

# 個人アカウント配下の確認
# 漏洩したトークンが開発者個人の PAT だった場合、
# tpcp-docs リポジトリは組織ではなく個人アカウント配下に作成される仕様のため、
# PAT を CI/CD に利用している開発者は個人アカウントも併せて確認することが推奨されます。
gh repo list  --limit 1000 --json name \
  --jq '.[] | select(.name | contains("tpcp-docs"))'

該当リポジトリが検出された場合は、即座にインシデントレスポンスの発動が推奨されます。

開発者マシン上の永続化ドロッパー（sysmon.py）確認

Aqua Security の公式アドバイザリでは、悪意のある Trivy バイナリを直接実行した可能性のある開発者マシンについて、以下のパスに永続化ドロッパーが残存していないかの確認が呼びかけられています。

参考: Aqua Security Update

“On developer machines where the malicious Trivy binary may have been executed, check for the persistence dropper at ~/.config/systemd/user/sysmon.py and associated systemd user unit files. Remove immediately if found.”

（悪意のある Trivy バイナリが実行された可能性のある開発者マシンでは、~/.config/systemd/user/sysmon.py に永続化ドロッパーが存在しないか確認が推奨されます。発見された場合は即時削除が推奨されます。）

https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

Linux/macOS 環境では以下のコマンドで確認します。

# 永続化ドロッパーの有無確認
ls -la ~/.config/systemd/user/sysmon.py 2>/dev/null

# 関連する systemd ユーザーサービスの確認
systemctl --user list-unit-files 2>/dev/null | grep -i sysmon

# 稼働中のプロセスの確認
ps aux | grep -i sysmon | grep -v grep

C2 ドメインへのアウトバウンド通信の遮断と監査

ネットワーク境界（ファイアウォール、プロキシ、クラウドの NSG 等）で、以下の IoC（Indicator of Compromise）へのアウトバウンド通信を遮断し、過去ログから該当通信の有無を確認することが推奨されます。

影響確認後のシークレットローテーション範囲

侵害期間内にパイプラインが実行されていた場合、そのランナー環境からアクセス可能だったすべてのシークレットが漏洩したと見なす対応が推奨されます。ローテーション対象は以下のとおりです。

• AWS / GCP / Azure のクラウド認証情報（IAM アクセスキー、サービスプリンシパル等）
• コンテナレジストリの認証情報（Docker Hub、GHCR、ECR、ACR 等）
• NPM / PyPI / RubyGems 等のパブリッシュトークン
• GitHub の Personal Access Token（PAT）および GitHub App のシークレット
• Kubernetes のサービスアカウントトークン、kubeconfig
• SSH キー、GPG キー
• Slack / Jira / Datadog などの連携 Webhook およびトークン

ここで重要なのは、初動の Trivy チームが経験したように、「アトミック（同時・網羅的）なローテーション」でないと残留アクセスの経路を残してしまう点です。単一のトークン回転ではなく、関連する全認証情報を同一インシデントウィンドウ内で一括無効化する手順の整備が推奨されます。

SHA Pinning の実装ガイドと自動化

今回の攻撃がこれほど広範囲に成功した最大の理由は、多くの組織が GitHub Actions を呼び出す際に、動的に上書き可能なバージョンタグ（@v1や@v0.28.0など）を利用していたためです。 GitHub の公式ドキュメントでも、サードパーティアクションを利用する際のベストプラクティスとして、フルコミット SHA へのピン留めが明確に推奨されています。

参考: GitHub Docs – Secure use reference

“Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release.”

（アクションをフルレングスのコミット SHA にピン留めすることが、現時点ではアクションをイミュータブルなリリースとして利用する唯一の方法です。）

https://docs.github.com/en/actions/reference/security/secure-use

Mutable Tag から Immutable Commit SHA への書き換え例

CI/CD パイプラインの YAML ファイルにおける、典型的な修正パターンを示します。

# ❌ Before: Mutable Tag（タグが force-push で書き換え可能）
- name: Run Trivy scanner
  uses: aquasecurity/trivy-action@v0.28.0

# ✅ After: Immutable Commit SHA（40 桁の完全なコミットハッシュ）
- name: Run Trivy scanner
  uses: aquasecurity/trivy-action@18f2510ee396bbf400402947b394f2dd8c87dbb0 # v0.28.0

コミット SHA に続けて# v0.28.0のようにコメントでバージョン名を併記することで、人間が読んだときにどのバージョンに固定しているかを把握しやすくなります。この記法は Dependabot や Renovate が正しく解釈できる標準的なスタイルです。

なお、ピン留めする SHA は必ず本家リポジトリ（fork ではない）のコミットであることを確認することが推奨されます。GitHub UI で該当コミットを開き、リポジトリのオーナーが公式アカウントであることを確認するプロセスを挟むと安全です。

Dependabot による SHA Pinning の自動更新

SHA にピン留めすると「バージョンアップ追従が面倒になる」という懸念が生じますが、Dependabot を組み合わせることで解決できます。 リポジトリのルートに.github/dependabot.ymlを配置します。

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    # セキュリティ更新は即時反映
    open-pull-requests-limit: 10

この設定により、Dependabot は SHA ピン留めされたアクションについても、新しいバージョンがリリースされるたびに自動的に PR を作成します。PR 上では SHA の差分と、コメント部のバージョン表記（# v0.28.0→# v0.29.0）の両方が更新されます。

参考: GitHub Docs – Keeping your actions up to date with Dependabot

https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

組織レベルで SHA Pinning を強制するポリシー設定

2025 年 8 月以降、GitHub Actions には組織・リポジトリ・Enterprise の各レベルで「SHA ピン留めを必須化する」ポリシーが追加されています。個別の開発者の裁量に任せるのではなく、組織の標準として強制できるようになった点は、ガバナンスの観点で大きな進歩です。

参考: GitHub Changelog – GitHub Actions policy now supports blocking and SHA pinning actions “For the GitHub Actions ecosystem, the benefits include the ability to pin tags with immutable references, preventing potential malicious updates to existing tags and enabling dependable updates via Dependabot.” （GitHub Actions エコシステムにおいては、タグをイミュータブルな参照でピン留めできるようになったことで、既存タグへの悪意ある更新を防ぎ、かつ Dependabot による信頼性の高い更新を実現する効果が期待できます。）https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/

ポリシーの設定手順:

組織レベルで有効化する場合

GitHub 組織の「Settings」→「Actions」→「General」を開き、「Policies」セクションの「Require actions to be pinned to a full-length commit SHA」を有効化します。既存ワークフローが違反していないか、CI で自動チェックする仕組みを併設することが推奨されます。

リポジトリレベルで有効化する場合

リポジトリの「Settings」→「Actions」→「General」から同等のオプションを有効化します。

参考: GitHub Docs – Disabling or limiting GitHub Actions for your organization

https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization

SHA Pinning だけでは防げない「間接的な侵害」への注意

SHA Pinning は極めて有効な対策ですが、呼び出し先のアクションがさらに別のアクションを動的に呼び出している場合、その部分までは保護できない点に留意が必要です。 今回の Trivy インシデントでも、象徴的な事例が報告されています。trivy-actionを安全なコミット SHA にピン留めしていても、そのアクションが内部で呼び出すsetup-trivyが侵害されていた場合、間接的に悪性コードが実行される可能性がありました。

参考: GitHub Security Advisory GHSA-69fq-xp46-6×23

“If you pinned trivy-action to a commit prior to that PR (merged 2025-04-09), then you would get a safe trivy-action but it would get a malicious setup-trivy, if invoked during the setup-trivy exposure window.”

（2025 年 4 月 9 日にマージされた PR 以前のコミットに trivy-action をピン留めしていた場合、安全な trivy-action を取得できる一方で、setup-trivy の露出時間帯にはその呼び出しが悪意のある版を取得する可能性がありました。）

https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6×23

この事例が示すのは、SHA Pinning は多層防御の一枚目に過ぎないということです。ランナー環境の監視、最小権限の GITHUB_TOKEN 設定、Egress 通信制御といった対策と組み合わせることで、初めて実効性のある防御が成立します。

また、GitHub が提供する「Immutable Release」バッジも万能ではありません。Aqua Security の公式アップデートでは以下のように注意喚起されています。

参考: Aqua Security Update

“GitHub’s ‘Immutable’ release badge does not prevent tag force-pushing.” （GitHub の「Immutable」リリースバッジは、タグの force-push を防ぐわけではありません。）

https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

今回、trivy-actionの v0.35.0 のみが無事だったのは、このタグが GitHub のイミュータブルリリース機能（2026 年 3 月 4 日に有効化）で個別に保護されていたためであり、バッジ表示そのものが防御となったわけではありません。

SHA Pinning 自動化ツールの比較と選定ガイド

SHA Pinning の有効性は前章で整理したとおりですが、手作業で全リポジトリのワークフローを書き換えるのは現実的ではありません。実運用では、既存ワークフローの SHA 化と、その後のバージョン追従を自動化するツールの活用が推奨されます。

主要ツールの比較表

各ツールの特徴と適した用途

Dependabot

GitHub 標準の依存関係更新ツールで、追加設定なしに利用できるのが最大の利点です。ただし、既存ワークフローの初回 SHA 化は手動で対応する必要があり、一度 SHA ピン留めされたアクションについて新バージョン公開時に PR を作成する動作となります。「まずは最小構成で運用を始めたい」「GitHub 標準機能で完結させたい」組織に適しています。

参考: GitHub Docs – Keeping your actions up to date with Dependabot

https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

Renovate

サードパーティ製の依存関係更新ツールで、設定の柔軟性が非常に高い点が特徴です。helpers:pinGitHubActionDigestsプリセットを有効にすることで、既存ワークフローのタグ参照を自動的に SHA ピン留めに変換する PR を生成できます。組織レベルの共通設定ファイル（renovate.json）を一元管理できるため、リポジトリ数が多い組織に向きます。

参考: Renovate Docs – GitHub Actions Manager

https://docs.renovatebot.com/modules/manager/github-actions

pinact

ワークフローファイルの SHA 化に特化した OSS CLI ツールです。既存の YAML を一括で SHA ピン留めに書き換える用途に最適で、CI 上で実行することで「新規ワークフローが SHA ピン留めされていなければビルドを失敗させる」といったゲート制御にも組み込めます。Dependabot や Renovate と組み合わせて利用する形が一般的です。

参考: pinact GitHub リポジトリ

https://github.com/suzuki-shunsuke/pinact

StepSecurity

CI/CD セキュリティに特化した SaaS で、SHA Pinning のほか、GITHUB_TOKEN の最小権限化、ランナー環境のアウトバウンド通信の異常検知（Harden-Runner）など、多層防御を一括で導入できる点が特徴です。Freemium モデルで OSS プロジェクトは無料利用が可能です。

組織規模別の選定指針

どのツールを選ぶかは、組織のリポジトリ数や運用体制によって変わります。以下は一つの目安です。

小規模（リポジトリ数 〜10 程度）

Dependabot 単体でも十分運用可能。初回の SHA 化は手動またはスクリプトで対応する。

中規模（〜100 程度）

Renovate または Dependabot + pinact の組み合わせが有効。初回の一括 SHA 化と継続的な更新を分業できる。

大規模（100 超）/ 規制業種

StepSecurity のような SaaS で組織横断の可視化・ポリシー強制を実装する選択肢も検討余地がある。

導入当初は「既存ワークフローの一括 SHA 化」と「新規ワークフローの SHA 必須化（組織ポリシー）」の両輪で進めることが推奨されます。既存の負債を返済しつつ、新たな負債が積み上がらない仕組みを同時に整備する考え方です。

まとめ

• Trivy 開発環境でのトークン漏洩が、一連の大規模サプライチェーン攻撃の起点となった。
• 攻撃者は既存のバージョンタグを強制上書きし、パイプラインからシークレットを窃取した。
• 3 月 22 日以降も Docker Hub イメージや内部リポジトリへの追加侵害が確認されている。
• 盗まれた NPM トークン等が即座に兵器化され、エコシステム全体へ二次被害が拡大している。
• 影響調査は gh CLI と IoC 確認、シークレットの網羅的（アトミック）なローテーションで対応する。
• GitHub Actions は不変のコミット SHA（Immutable Commit SHA）へのピン留めと、Dependabot や Renovate 等による自動更新の組み合わせが有効である。
• SHA Pinning は万能ではないため、組織ポリシーでの強制化やランナー環境の監視と組み合わせた多層防御を検討することが推奨される。

以上、最後までお読みいただきありがとうございました。