ソフトウェアサプライチェーンの構造的リスクとコンテナ環境の保護

セキュリティ・キャンプ全国大会2026のB6講義資料です。

Transcript

1. ソフトウェアサプライチェーンの構造的リスクと コンテナ環境の保護 セキュリティ・キャンプ全国大会2026 B6 @kyohmizu
2. 資料置き場 講義資料は以下の GitHub リポジトリに置いています。手元で参照しながら進めてください。 github.com/kyohmizu/seccamp2026-B6
3. 自己紹介 水元 恭平 株式会社スリーシェイク 事業部 ／ セキュリティエンジニア（兼マネージャー） Sreake クラウド＆コンテナセキュリティを専門に、顧客企業の技術支援をしています 金融システムの CSIRT 支援 セキュアな Kubernetes システムの構築 Google Cloud 環境のセキュリティ評価 チャット連携されるAIエージェントのセキュリティ評価 その他の活動 クラウドネイティブとセキュリティの両コミュニティで活動しています セキュリティ・キャンプ全国大会2024、2025講師 「コンテナセキュリティ」書籍監訳 「セキュアAPI」書籍翻訳
4. 講義の目的 現代の開発・運用現場に潜むサプライチェーンの構造的リスクを体系的に把握し、限られたリソースの中で優先すべき対 策を自ら判断できる状態を目指す。 第1章 構造的リスク: インシデントから手口を学び、開発ライフサイクルの段階と人・プロセス・技術の軸でリスクを整理する 第2章 脅威モデリングと対策: 脅威を洗い出す枠組みと、対策のフレームワーク・選定の観点を押さえる 第3章 演習: Google Cloud 環境で、取得・ビルド・デプロイ・実行時の多層防御を手を動かして体験する 座学（第1〜2章）で全体像をつかみ、演習（第3章）で対策を実装する構成。
5. 題材: 架空の Fintech「PayLoad 社」 架空の Fintech スタートアップ「株式会社 PayLoad」を題材とします。 法人向け経費精算プラットフォーム「FlowPay」を運営 コンテナ技術と OSS パッケージを活用して急成長 大手金融機関との業務提携に伴い、後回しにされていたセキュリティとガバナ ンスの強化が急務 npm や CI/CD を狙う攻撃の多発と提携先からの照会を受け、経営層がソフト ウェアサプライチェーン対策を最優先の経営課題に位置づけ 経費精算サービス FlowPay の画面 あなたは、その推進を命じられた PayLoad 社のセキュリティ担当者です。
6. FlowPay の環境 Google Cloud 開発者 push GitHub （FlowPay） リポジトリ Cloud Run Cloud Build イメージビルド パッケージレジストリ npm / Go modules push Artifact Registry コンテナイメージ 時起動 push デプロイ Cloud Build デプロイ 依存取得 デプロイ Webアクセス backend （ ） frontend Node.js 呼び出し （Go 経費API） API 利用者 → Cloud Build → Artifact Registry → Cloud Run のマイクロサービス構成 frontend: npm の OSS に依存する Node.js アプリ / backend: Go の経費精算 API frontend は backend を ID トークン認証で呼び出し。両サービスとも**非公開（private）**の Cloud Run 上で稼働（動作確認は gcloud run services proxy 経由） GitHub
7. 演習環境の確認 環境の稼働と、自分のコード変更が CI/CD を通じてデプロイされる流れを確認する。 1. サービスへの接続確認 FlowPay private な Cloud Run にプロキシ経由で接続し、画面を確認する gcloud run services proxy app-<NN>-frontend --region asia-northeast1 --port 8080 経費一覧・サマリ・カテゴリ別内訳が表示されれば、frontend → backend（ID トークン認証）のサービス間通信も正常 2. コード変更で CI/CD を一周 無効化されている「カテゴリ絞り込み」を有効化（ frontend/public/index.html のコメント解除のみ） main へ push → Cloud Build → Artifact Registry → Cloud Run へ自動反映されることを確認 この push → build → deploy のパイプライン自体が、第3章で堅牢化していく対象。 詳細な手順: chapter1/environment-check.md
8. 第1章 構造的リスク
9. 第1章で扱うこと 導入: サプライチェーン攻撃の定義、ソフトウェアサプライチェーンの範囲、攻撃の深刻化（件数・速度・自動化） 1-1 インシデントから学ぶ: Shai-Hulud・axios・TanStack・Trivy 等の最新事例（手口・狙われた段階・弱点） 1-2 構造的リスクの整理: 段階（Source〜Runtime）と人・プロセス・技術の軸で事例を構造化。防御を困難にする要因 1-3 攻撃デモ: FlowPay 上で悪性依存の取り込みを再現し、侵害の成立を確認
10. サプライチェーン攻撃とは の定義: 「少なくとも 2つの攻撃の組み合わせ」 一次ターゲットの供給元（サプライヤー）を最初に侵害し、そこを踏み台に本来の標的へ到達する多段階の手法。標的を 直接攻撃せず、標的が信頼する外部の供給経路を経由して侵入する。 ENISA 本質は、暗黙の信頼の連鎖を悪用した上流から下流への侵入にある。 （ ）＝ 初期侵入（Initial Access）の主要テクニック ここを足がかりに、認証情報の窃取・横展開・永続化へと攻撃フェーズが進行する MITRE ATT&CK T1195 Supply Chain Compromise 出典: ENISA『Threat Landscape for Supply Chain Attacks』(2021) / MITRE ATT&CK T1195
11. 侵害経路による3分類 侵害経路に応じて大きく 3つに分類される。本講義の主要対象はソフトウェアサプライチェーン攻撃。 分類 ソフトウェア サービ ス ビジネス（事 業） SaaS/ 概要 ソースコード・依存ライブラリ・CI/CD ツール・ビルド環境を改ざんし、正規の配信経路で展開（SolarWinds / XZ Utils / axios）。自社パイプラインを乗っ取る PPE も含む 稼働中の外部 SaaS・運用ベンダーの信頼（API キー・OAuth トークン・リモート管理権限）を侵害し顧客環境へ侵入 業務委託先・調達先パートナー・ハードウェアベンダー等、事業を支える取引先の連鎖を踏み台にする
12. 供給網を守る2つの視点 ソフトウェアサプライチェーンセキュリティは、供給網全体を保護する包括的な取り組み。立場によって守るべき対象が 異なる。 供給元（プロバイダー）としての保護: 自社成果物・製品の改ざんを防ぐ（デジタル署名・provenance の付与・ビルド環境の堅牢 化） 利用側（コンシューマー）としての保護: 導入する外部コンポーネント・ツールのリスク管理（SBOM による構成部品の把握・脆弱 性管理・VEX による評価） FlowPay なる。 は OSS を利用する立場（コンシューマー）であると同時に、FlowPay 自体を提供するプロバイダーでもある。両面の視点が必要に
13. ソフトウェアサプライチェーンとは （依存ライブラリの脆弱性管理）と同義に捉えられることもあるが、実際はより広範な概念。 設計・開発・ビルド・テスト・パッケージング・配布・デプロイ・運用に至るまで、直接的または間接的に関わるすべて の構成要素の連鎖を指す。 SCA 人: 社内開発者・外部委託先エンジニア・システム管理者・OSS メンテナ プロセス: コードレビュー・承認・リリースフローを定めた運用ルール・ガイドライン 技術・インフラ: 開発端末環境・CI/CD パイプライン・コンテナレジストリ・ビルドサーバー・配信インフラ これら全構成要素の完全性・信頼性・回復力を、ソフトウェアの全ライフサイクルにわたって確保する取り組み。
14. 深刻化するサプライチェーン攻撃 万件 + 年に新規検知された悪性 パッ 40 2025 OSS ケージ（うち 99%+ が npm に集中） 32% 公開から 24時間以内に悪用された脆弱 性（2025 前半） 分 初期侵入から横展開までの平均時間 29 （最速記録は 27秒） レジストリが優先的に狙われる理由: 単一拠点の侵害で多数の利用企業へ効率的に被害を拡散できる 境界防御（Perimeter Defense）を強固にしても、信頼された供給経路経由の侵入は防げない AI による脆弱性発見の高速化: AI エージェントによる未知のゼロデイの自動発見も現実となり、兵器化までの時間が一層短縮 出典: Sonatype 2026 / VulnCheck 1H-2025 / CrowdStrike 2026
15. 1-1 インシデントから学ぶ
16. 事例1: Shai-Hulud（自己増殖型ワーム） 年9月、npm エコシステムで初となる自己増殖型ワーム。開発者の認証情報を窃取し、その権限で自身が管理する他 パッケージへ悪性コードを自動注入・再パブリッシュする動作を連鎖的に繰り返す。 2025 従来は「不審なパッケージを手動で特定・削除」する後手の対応が中心 ワーム化により、拡散が人手の対応速度を上回るフェーズへ移行した 攻撃が手動操作から自動化された自己増殖フェーズへ移行。開発者アカウントの侵害が、パイプラインおよびクラウド基盤全体の掌 握に直結することを証明した。 出典: Datadog Security Labs / Unit 42 / Wiz
17. 事例1（続き）: Shai-Hulud 2.0（高度化した第二波） 2025 年11月、高度化した第二波が発生し、約 800個のパッケージが汚染被害を受けた。 検知回避: Node.js 標準の監視・検知を回避するため、JavaScript ランタイム Bun 環境上で動作 資格情報の収集: ローカルの認証情報に加え、クラウドのメタデータサービスやシークレット管理（AWS Secrets Manager / Azure Key Vault / Google Cloud Secret Manager）から自動収集 大量バックドア化: 窃取トークンを用いて最大 100個のパッケージを自動的にバックドア化 永続化: 感染環境を GitHub Actions のセルフホストランナーとして自動登録し、常駐化 狙われた段階: Package（悪性パブリッシュ）＋ Build（GitHub Actions の不正利用） 弱点: 人（トークン窃取）＋技術（CI/CD の不備）
18. 事例2: axios（メンテナアカウントの奪取） 年3月、広く利用される HTTP クライアント axios の悪性バージョン（1.14.1 / 0.30.4）が公式レジストリにパブリ ッシュされた。リードメンテナ PC へのソーシャルエンジニアリングとマルウェア感染により、npm のパブリッシュ認証 情報が奪取されたことが直接の原因。 2026 本体ソースコードは直接改ざんせず、新設の外部依存 plain-crypto-js を読み込ませる多段階構成 インストール時に自動実行されるフック（ postinstall ）を悪用し、クロスプラットフォーム対応の RAT を展開 広く信頼されるライブラリでも、安全性は個人のアカウント認証情報管理に強く依存する。新規の外部依存を追加する隠蔽は通常の レビューを迂回する。公開直後の数時間が被害のピーク → cooldown（待機期間）設定が有効な予防策。 狙われた段階: Source（メンテナ資格情報）→ Package（不正パブリッシュ） 弱点: 人（アカウント管理） 出典: Huntress / Orca Security / axios issue #10636
19. 事例3: TanStack（正当な署名を持つ悪性パッケージ） 年5月、Web フレームワーク群 TanStack の 42個のパッケージで 84個の悪性バージョンがパブリッシュされた。攻撃 グループ TeamPCP の手順: 2026 フォークリポジトリからの Pull Request を契機に pull_request_target イベント（Pwn Request）を起動 2. 本家リポジトリの信頼境界を越えて GitHub Actions のビルドキャッシュを汚染 3. CI ランナーのプロセスメモリ空間から OIDC 一時トークンを抽出 4. 抽出トークンで悪性バージョンを正規パイプライン上でビルド・パブリッシュ 汚染パッケージに正当な SLSA provenance が付与されていた。正規 CI ランナー上で処理されたため、Sigstore 経由で本物の署名と provenance が自動生成・発行された。 → 署名・provenance の検証は重要だが、ビルド環境自体が侵害されれば正当な署名を持つ悪性成果物が生成される。ソース・ビルド・検 証・デプロイの各段階で防御を重ねる多層防御（Defense in Depth）が不可欠。 1.
20. 事例4: Trivy（セキュリティツール自身の侵害） 年3月、脆弱性スキャナー Trivy の GitHub Action が攻撃グループ TeamPCP によって侵害された。 aquasecurity/trivy-action の 76タグ中 75タグ、 setup-trivy の 7タグが悪性コミットへ force-push（可変タグの 書き換え）され、タグ指定で参照する CI が悪性バージョンを取り込んだ。悪性の Trivy 本体バイナリ（v0.69.4）も GitHub Releases / Docker Hub / GHCR / ECR に公開された。 2026 初期侵入: 先行インシデントの封じ込め不備で残存した権限を起点に、正規メンテナを装う偽装コミット（imposter commit）でタ グを付け替え 情報窃取: ランナーのプロセスメモリ（ Runner.Worker ）から isSecret のマスク対象を直接抽出。SSH 鍵・クラウド認証情報 （AWS/Google Cloud/Azure）・K8s トークンも収集 外部送信と常駐化: typosquat ドメインへ暗号化送信。端末上に Python 製バックドアを常駐化 二次被害: 窃取した npm トークンでワーム（CanisterWorm）を拡散。他 Aqua OSS（tfsec 等）・内部認証情報にも波及 「守るためのツール」自体が侵入経路になり得る（Codecov と同じ構図）。可変タグ参照はタグを差し替えられただけで CI 全体が汚 染される → Action はフルコミット SHA で固定（pinning）。演習02の digest 固定と同一原則。 出典: Wiz
21. 過去の代表的インシデント 年 事例 2017 NotPetya 2018 Event-Stream 2020 SolarWinds 2021 Codecov 2021 Dependency Confusion 帰結・教訓 会計ソフトの更新サーバーが侵害され、正規アップデートとしてマルウェアを全社配信。配信チャネル 自体が攻撃インフラに変化 OSS の保守権限を引き継いだ攻撃者が暗号資産鍵を窃取する依存を追加。メンテナ権限譲渡に潜むソー シャルエンジニアリング ビルドパイプラインへ侵入し、コンパイル時にバックドアを自動注入。ソースが正常でもビルド工程で 汚染される CI 用 bash スクリプトが改ざんされ環境変数（API キー等）が流出。計測・セキュリティ用外部ツール自 体が侵入経路化 社内限定パッケージと同名かつ高バージョンの偽パッケージを公開レジストリへ配置。名前解決仕様を 悪用した非脆弱性型攻撃 更新配信経路の悪用・メンテナ乗っ取り・ビルド工程侵害という根本原理は共通。変化したのは到達規模・拡散速度・完全自動化の度合 い。特定の脅威に依存しない汎用的な防衛策の構築が不可欠。 出典: CISA（NotPetya / SolarWinds）/ Codecov ポストモーテム / event-stream #116 / Alex Birsan（Dependency Confusion）
22. 事例の共通点 事例 狙われた段階 Shai-Hulud Package / Build axios Source / Package TanStack Build SolarWinds Build tj-actions Build Trivy Build 人 • • プロセス 技術 • • • • • • • • 攻撃は Package（レジストリ）と Build フェーズに集中。ソースコードより取得・ビルド工程が主要標的 2. 弱点は技術的要因にとどまらず、人（認証情報管理）やプロセス（レビュー・運用ルール）の不備に深く起因 3. 手法は必ずしも高度ではなく、無差別に窃取した認証情報で自動横展開する事例が多い 1.
23. ソフトウェアサプライチェーンの現状について 被害は続いているが、絶望する必要はない そもそも・・・ コンピュータやインターネットの土台は、安全を前提にせず作られた 平文の HTTP TLS 化が進んだのは過去10年（2013年のスノーデン事件以降） 認証も Passkey の時代へ たくさんの被害ののちに生まれてきた （被害の後）証券会社がPasskey必須化に取り組むように まだ直っていないものもある オンプレADは、いまだに標的型攻撃・レッドチームの主戦場 サプライチェーンセキュリティも、単にまだ整ってない状況の一つ ポジティブに考えると、これから直すべきことがたくさんあるフロンティア いろいろなものが生まれているが、まだ点が線になっていない状況 Secure by default ではない 色々なプレイヤーが今も色々なことを考えている 出典: サプライチェーンセキュリティの空白地帯 - 信頼できる”依存性”の未来を考える（rung, slide 23・25） speakerdeck.com/rung/20260604-supply-chain-security
24. 1-2 構造的リスクの整理
25. ソフトウェアサプライチェーンの全体像 保護対象となるソフトウェアサプライチェーンは、大きく2つに大別される。 自社開発ソフトウェアのサプライチェーン: 自社が書くコード＋依存 OSS 群。直接依存に加え、ライブラリがさらに参照する推移的 依存（Transitive Dependencies）が存在する（直接依存が数十件でも、推移的依存を含めると数千件に膨れ上がることが一般的） 外部ツールのサプライチェーン: 監視エージェント・開発プラグイン・CI/CD 実行基盤・外部 SaaS など（信頼して導入したツールが 侵害されると、正規アップデートや付与された権限を悪用した侵入が発生する） アプリケーション本体・ライブラリ・CI/CD・ベースイメージ・IaC・監視 SaaS のすべてが防御対象範囲に含まれる。
26. 開発ライフサイクルの5段階 サプライチェーンは Source → Build → Package / Distribution → Deploy → Runtime の 5段階で整理できる。 段階 Source Build Package / Distribution Deploy Runtime 主な攻撃面 開発者アカウント・リポジトリ 設定 CI/CD ランナー・ビルド定義・ シークレット レジストリ・自動実行フック デプロイ経路・配布パイプライ ン コンテナ実行環境・ネットワー ク通信 代表的な攻撃例 メンテナ乗っ取り・Pwn Request ビルド改ざん・PPE・メモリからのトークン抽 出 Typosquatting・Dependency Confusion・悪性 バージョン公開 未検証・改ざんイメージの配置 不正コードの実行・C2 通信 代表的な対策 MFA・ブランチ保護・複数人レビュー・コミット署名 隔離・使い捨てビルド環境・provenance 生成・最小権 限・SHA 固定 署名検証・cooldown 運用・プライベートレジストリ・ Trusted Publishing デプロイ時検証（Binary Authorization）・admission 制 御・署名検証 実行時モニタリング（eBPF）・Egress 制限・最小権限・ネ ットワークポリシー
27. コンテナ特有のリスク構造 コンテナイメージの配布・利用では、そのレイヤー構造に起因する固有のリスクが生じる。 多重の依存構造: 自社アプリ・OS・システムライブラリ・各種パッケージを積層。ベースイメージの脆弱性もそのまま継承される 可変タグリスク: node:20 などの可変タグはビルド実行時期で取得内容が変わる → ダイジェスト（ @sha256:... ）による固定 （ピン留め）が不可欠 公開レジストリの汚染: Docker Hub 等での悪性イメージ配置・フィッシング誘導（Graboid ワーム等） 取得時・導入時の即時実行リスク: イメージの取得・デプロイがそのままコード実行に直結。取得時検証を欠くと即座に侵害される 構成・設定ファイルの保護: イメージ本体だけでなく Dockerfile・K8s マニフェスト・Helm チャートの改ざん防止も必要 出典: Unit 42（Graboid）/ JFrog / 参考: コンテナサプライチェーンのリスクと対策（kyohmizu）
28. 主要な攻撃手法（1）Source・Build Source メンテナアカウントの乗っ取り: 資格情報を奪い、正規のパブリッシュ権限で悪性コードを配信 悪意ある貢献者: 長期間の正規貢献で信頼を得た後に悪性変更を注入（XZ Utils） Pwn Request: pull_request_target 等の設定不備を突き本家権限を奪取 Build ビルド処理の改ざん: コンパイル時等に悪性コードを自動注入 Poisoned Pipeline Execution (PPE): CI 設定を改ざんし、パイプラインの権限範囲で任意コードを実行 ランナー・キャッシュ汚染: メモリ空間や共有キャッシュから認証情報を抽出・窃取
29. 主要な攻撃手法（2）Package / Distribution・Deploy・Runtime Package / Distribution 類似名の悪性パッケージで誤導入を狙う Dependency Confusion: 内部と同名で、より高いバージョン番号の悪性パッケージを公開レジストリへ Slopsquatting: AI がハルシネーションで生成される存在しない名前を先回り登録。Copilot 等 AI 補完が提案する実在しないパッケ ージ名を無検証で npm install する Package Hallucination と表裏一体 インストールフックの悪用: postinstall 等で悪性コードを自動実行 Typosquatting: Deploy 更新経路の不正利用: 正規の更新配信サーバーや署名鍵を悪用し悪性アップデートを配布 Runtime 自動自己増殖（ワーム）: 窃取した認証情報で他パッケージへ自動的に感染を拡大
30. 人・プロセス・技術の3軸 人: アカウント乗っ取り・内部不正・委託先のセキュリティ管理不備（→ 多要素認証（WebAuthn/Passkey）の徹底・委託先のセキ ュリティ評価・最小権限の原則） プロセス: レビュー・リリースプロセスの不備（レビューを経ない直接 push の許可、Bot・ドキュメント更新のレビュー免除ルール の不適切運用が重大な抜け穴に） 技術・インフラ: ビルド・デプロイ基盤自体の堅牢化（隔離された使い捨て（ephemeral）ビルド環境・署名と provenance の自動生 成・依存のコミット SHA 固定） 単一の要素に偏らず、これら 3軸を統合して体系的に対策を講じる必要がある。
31. 脆弱性と悪性コードの違い サプライチェーン攻撃で問題になる悪性コードの挿入は、一般的な既知の脆弱性（CVE）と異なり、従来の検出手法が適 用しにくい構造的特徴を持つ。 評価項目 発生原因 検出難易度 発動契機 影響範囲 脆弱性（CVE） 意図しないバグ・設計上の不備 SCA ツールで自動検出可能 外部からの脆弱性攻撃リクエスト 主に本番・実行環境 悪性コードの混入 攻撃目的で意図的に挿入された悪性コード CVE が割り当てられず、既存ツールでの検出が困難 パッケージの導入・ビルド時に自動実行 開発者端末・CI/CD パイプライン環境へ即座に波及 悪性コードは CVE が付かず SCA で検出しにくい。しかも導入・ビルド時点で自動実行され、開発者端末や CI/CD へ即座に波及す る。
32. 防御を困難にする構造的要因 管理境界外からの侵入: 自社の資産管理（ASM）の範囲外である外部サプライヤーが起点となり、従来の境界防御が機能しない 2. 責任分界点の曖昧さ: サードパーティ Action や外部 SaaS 連携など、管理責任の境界が曖昧な領域が格好の標的になる 3. 生成 AI によるコード欠陥・ハルシネーション: AI 生成コードの潜在バグや、存在しないパッケージ名の誤提案（Slopsquatting） 4. 極めて複雑な推移的依存関係: 依存階層が深く、ソースコード全体の把握と手動レビューが現実的に不可能 5. ビルド環境侵入による暗号署名の無力化: 正当なビルド基盤が侵入されれば、正当なデジタル署名を持つ悪性成果物が生成される 1. 単一の防御では不十分。ソース・ビルド・検証・デプロイ・実行の各段階で防御を重ねる多層防御が前提になる。
33. 1-3 攻撃デモ
34. 攻撃デモの概要 環境を用いて、実際のサプライチェーン攻撃手法を再現する。題材は frontend が直接依存する金額整形ライブラ リ expense-format 。 FlowPay 攻撃者がメンテナ権限を奪取し、悪性バージョン expense-format@1.0.1 （悪意ある postinstall を含む）をパブリッシュ 2. Cloud Build で依存インストール時に postinstall が自動実行。メタデータサーバーから Cloud Build 用 SA のアクセストークンを 取得し外部 C2 サーバーへ送信 3. 悪性パッケージを含むイメージがデプロイされると、実行時にも Cloud Run 実行用 SA のアクセス証明が外部へ送信される postinstall を悪用した axios、CI からトークンを抽出した Shai-Hulud を再現。曖昧なバージョン指定（ ^1.0.0 ）とロックファイル の未固定が侵入経路になる。 1. デモの悪性コードは安全性を確保したシミュレーション。実際のアクセストークン自体は送らず、SA 名・トークン長・SHA-256 ハッシュ値・接頭辞等のア クセス証明のみを演習用 C2 サーバーへ送信する。 詳細な手順とコマンド: chapter1/attack-demo.md
35. 攻撃デモの流れ 1. 正常時 expenseformat@1.0.0 lockfile ci を で固定・npm で運用 攻撃者が悪性バー ジョン 1.0.1 を公開 ^1.0.0 の範囲内・ postinstall を埋め込み 2. → 依存更新 PR （Dependabot 相当） lockfile が 1.0.0 → 1.0.1・ hasInstallScript: true 追加 3. → マージ前 PR チェッ ク CI postinstall が自動実行 → ビルド用 SA トーク ンを窃取 4. → マージ・デプロイ 後の実行時 formatYen 呼び出しご とに実行用 SA トーク ンを継続送信 5. → 侵害はマージ前の PR チェック CI の時点で既に成立する。「レビューで違和感に気づけば防げる」という前提は機能せず、未検証の依存を CI 環境で実行し た時点で侵害が発生する。
36. C2 が受信した窃取データ のビルド時（ postinstall ）と Cloud Run の実行時（ formatYen ）に、それぞれビルド用・実行用の SA トークンの証拠が C2 サーバーへ送信された。 Cloud Build $ docker logs -f attacker-receiver C2 receiver listening on 0.0.0.0:9099 (POST /steal, GET /log) [C2 #1] 2026-08-13T05:27:42Z from 34.85.xx.xx # Cloud Build 受信 {"stage":"postinstall","host":"60cc14a5c896","user":"root", のジョブ上 "cwd":"/workspace/frontend/node_modules/expense-format","secretEnvKeys":[], "saTokenProof":{"sa":"310...40-compute@developer.gserviceaccount.com", "tokenLen":1024,"tokenSha256":"205a91d0…","tokenPrefix":"ya29.…"}} [C2 受信 #2] 2026-08-13T05:33:56Z from 35.243.xx.xx # Cloud Build のジョブ上 {"stage":"postinstall","host":"154288ca0ec5","user":"root", "cwd":"/workspace/frontend/node_modules/expense-format","secretEnvKeys":[], "saTokenProof":{"sa":"310...40-compute@developer.gserviceaccount.com", "tokenLen":1024,"tokenSha256":"018616d1…","tokenPrefix":"ya29.…"}} [C2 受信 #3] 2026-08-16T17:08:47Z from 34.34.xx.xx # Cloud Run の実行時（formatYen 呼び出し） {"stage":"runtime","event":"formatYen","stolen":71580, "saTokenProof":{"sa":"app-01-frontend-sa@seccamp.iam.gserviceaccount.com", "tokenLen":1024,"tokenSha256":"f2d4d132…","tokenPrefix":"ya29.…"}} ...
37. 第2章 脅威モデリングと対策
38. 第2章で扱うこと 脅威モデリング: システムを俯瞰し、信頼境界を跨ぐ流入点（＝攻撃経路）を洗い出す。FlowPay を題材に演習 2-2 対策の枠組みと観点: 基本原則・主要フレームワーク・目的別対策で体系的に整理。 2-1
39. 2-1 脅威モデリング
40. 脅威モデリングとは システム全体を俯瞰し、アタックサーフェスや攻撃手法を事前に予測・特定する構造的な取り組み。 狙い: 攻撃対象となり得る領域と攻撃経路を、設計段階で洗い出す 枠組み: Adam Shostack の Four Question Framework（特定の手法に依存しない基本プロセス） 脅威一覧の網羅性そのものが目的ではない。関係者がシステム構造の理解を深め、設計段階の弱点に自主的に気づくプロセスに価値 がある。
41. つの問い 4 （特定の手法に依存しない枠組み） Four Question Framework 何を作っているか（What are we working on?）: 構成要素とデータフローを定義。DFD や構成図などに信頼境界を引く 2. 何が起こり得るか（What can go wrong?）: 脅威を洗い出す（STRIDE 等の手法を枠組みの中で使う） 3. どう対処するか（What are we going to do about it?）: 低減・除去・移転・受容から選び優先順位づけ 4. 妥当性を検証できたか（Did we do a good job?）: 設計と構成図の整合、網羅性、記録・追跡を評価 1. 出典: Threat Modeling: Designing for Security（Adam Shostack）/ Threat Modeling Manifesto
42. 脅威を洗い出す手法 目的に応じて選択・併用する。 なりすまし・改ざん・否認・情報漏洩・DoS・権限昇格の6観点で、要素ごとに漏れなく列挙する汎用手法 Attack Tree: 攻撃者の最終目標（例: 本番への悪性コード到達）を頂点に、手段を階層分解して侵入パスを特定 PASTA: 攻撃シミュレーションからビジネスリスク評価まで段階的に進めるプロセス指向の手法 攻撃カタログとの照合: MITRE ATT&CK・OSC&R・SITF・OWASP Top 10 CI/CD などの既知フレームワークで網羅性を検証 STRIDE: 出典: Threat Modeling: 12 Available Methods（SEI）
43. 脅威モデリング演習（FlowPay） 信頼境界を跨ぐ流入点から具体的な脅威を洗い出し、各対策が「どの脅威に有効か」を対応づけられるようにする。 ③ PayLoad 組織内（ビルド系） ② 開発者 社内開発者 ソースコード管理 リポジトリ GitHub 委託先/オフショア開発者 ④ 本番環境（Google Cloud） イメージ push 依存取り込み コンテナレジストリ deploy Artifact Registry パイプライン CI/CD GitHub Actions Runner 実行 Action 参照 シークレット/認証 ・OIDC・各種 トークン Google Cloud ① 外部（信頼境界外・OSSエコシステム） パッケージレジストリ OSS npm / PyPI / Go modules FROM Cloud Run FlowPay サービス サードパーティ GitHub Actions ベースイメージ Docker Hub 等 SaaS監視/ログ エージェント・プラグイン 破線枠は信頼境界。Cloud Run と GitHub Actions を中心に整理・単純化した構成。 自動更新 決済・個人データ Cloud SQL
44. 暗黙の信頼が存在する領域 構成図上で「相手を信頼して受け入れている」箇所が攻撃の起点になる。 ① → ③ 外部成果物の取り込み: OSS パッケージ・サードパーティ Action・ベースイメージの完全性と正当性を前提にする ② → ③ 開発者アカウント: 業務委託先を含む開発者の正当性と、コミットされるコード内容を信頼する ③（CI）→ ④ デプロイ: CI 上で構築した成果物を正規と見なして本番へデプロイする ③（CI）↔ シークレット/認証情報: CI に本番デプロイ可能な広範な権限・認証情報（Google Cloud・OIDC・各種トークン）へのア クセスを許容する
45. 演習の手順 信頼境界の跨ぎ（境界通過ポイント）を確認し、攻撃者の侵入経路（流入点）を特定する。優先的に狙われる領域とその技術的理由 も考察する 2. ワークシートで、各流入点の「信頼の前提」「想定される攻撃手法」 「影響範囲（単一侵害時）」を抽出する。攻撃手法は SITF の攻 撃テクニックや実例（Shai-Hulud・tj-actions・TanStack など）を参照して具体化する 3. 流入点を1つ選び、 「流入点 → 信頼の前提 → 攻撃手法 → 影響範囲 → 防御策」で構造化する。防御策の回避手法や残存リスクも検討 する ワークシート 1. 流入点 npm 依存の取り込み （①→③） 信頼の前提 公開パッケージ は安全 詳細な手順: chapter2/threat-modeling-exercise.md 想定される攻撃手法 メンテナ乗っ取りによる悪性バ ージョン公開 影響範囲 ビルド〜本番（認証情 報窃取） 防御策 依存パッケージ の固定
46. 攻撃テクニックの一覧: SITF 。開発から本番稼働までを5レイヤーに区分し、攻撃を ID・ステージ・手法・リス SDLC Infrastructure Threat Framework ク要因・対応策として整理。 端末・IDE（T-E）: 悪性コード実行（T-E001）・拡張機能の自動更新悪用（T-E015）・OAuth トークン悪用（T-E019） VCS（T-V）: Imposter Commits（T-V002） ・タグ参照の改ざん（T-V011）・フォーク間参照の悪用（T-V012） CI/CD（T-C）: Pwn Request / PPE（T-C003） ・認証情報の不法使用（T-C001）・シークレット抽出（T-C005） レジストリ（T-R）: 悪性パッケージ公開（T-R004）・Typosquatting（T-R010）・Dependency Confusion（T-R011）・インストール フック悪用（T-R012） 本番・クラウド（T-P）: CI/CD 由来の本番認証情報の悪用（T-P001）・本番からのシークレット窃取（T-P011）・データ持ち出し （T-P013） 出典: SITF（SDLC Infrastructure Threat Framework, Wiz） https://wiz-sec-public.github.io/SITF/techniques-library.html 日本語版（参考）: chapter2/sitf-technique-library.md
47. 流入点 × インシデント × 対策 演習で脅威を洗い出す際の参考。代表的な流入点を、実際のインシデントと主な防御策に対応づけた一覧。 流入点 OSS 依存の取り込み（①→CI） サードパーティ Action（①→CI） ベースイメージ（①→CI） 委託先・開発者アカウント（②→SCM） CI/CD ランナー（③内部） ビルド成果物のデプロイ（CI→④） SaaS 監視/ログの自動更新（①→④） シークレット参照（CI↔SEC） 実際のインシデント Shai-Hulud・axios tj-actions 汚染イメージ導入 axios・XZ Utils Shai-Hulud 2.0・TanStack TanStack ・ 各種トークン漏洩 Codecov SolarWinds 主な防御策 SCA/SBOM・cooldown・ --ignore-scripts ・検疫プロキシ コミット SHA 固定・最小権限・Ruleset 署名済み distroless・イメージスキャン MFA/Passkey・ブランチ保護・複数人レビュー OIDC 短命トークン・ランナー隔離・Egress 制限 cosign 署名・provenance 検証（Binary Authorization） 外部ツールのリスク評価・Egress モニタリング 長寿命鍵の廃止（Trusted Publishing/OIDC）・スコープ限定
48. 2-2 対策の枠組みと観点
49. 対策の全体像 サプライチェーンの防御策を、次の流れで整理する。 基本原則: 最小権限・多層防御など、あらゆる対策の土台 主要なフレームワーク: SLSA・SSDF など、体系化された基準・ガイド 目的別の具体策: 「どの脅威に有効か」で分類した対策の一覧 選定の観点と現実的な制約: 限られたリソースでの優先順位づけ
50. セキュリティの基本原則 サプライチェーン固有の対策も、共通の基本原則の具現化。 最小権限: ビルド SA・トークン・実行 ID を絞り、窃取後の横展開を抑止 職務分掌: ビルドとデプロイを分離し、CI 単独で本番反映させない 多層防御: 取得・ビルド・デプロイ・実行の各層で検証（署名だけでは不十分） ゼロトラスト: 「公式にある／署名がある」だけで信頼せず検証（Never trust, always verify） セキュリティ・バイ・デザイン: 設計段階から依存固定・署名検証・ビルド/デプロイ分離を組み込む 責任共有・シフトダウン / シフトレフト: 共通基盤で一括適用し、早期段階で遮断 出典: CNCF Cloud Native Security Whitepaper / Kubernetes SIG-Security Shift-Down Security Paper
51. 主要なフレームワーク （ ） TUF（The Update Framework） S2C2F（Secure Supply Chain Consumption Framework） SLSA Supply-chain Levels for Software Artifacts OSPS (Open Source Project Security) Baseline
52. SLSA （Supply-chain Levels for Software Artifacts） 成果物の完全性と来歴（provenance）を段階レベルで定義。最新は v1.2（2025年11月承認）。 Build Track（L1〜L3） が存在 L2: 改ざん耐性のある provenance をホスト型ビルドが生成 L3: ビルド環境を分離し他プロセス・テナントの干渉を防ぐ L1: provenance （ Source Track v1.2 で新設） ソースの変更履歴・レビュー運用を定義 L2 以上でブランチ履歴の連続性・不変性、source provenance attestation の発行 GitHub Actions + slsa-github-generator 出典: SLSA v1.2 Specification / v1.2 発表（2025年11月） で Build L2 相当を手早く導入できる。検証は slsa-verifier 。
53. （ ） TUF The Update Framework ソフトウェア更新（アップデート）の仕組みを保護するフレームワーク。配信元やリポジトリが侵害されても、クライア ントが悪性の更新を受け入れないようにする（例: NotPetya のような更新配信の侵害）。 鍵の役割分離としきい値署名: 暗号署名鍵を役割ごとに分け、しきい値署名を採用。一部の鍵が漏洩しても更新プロセス全体を防衛 する 役割は Root（信頼の起点）・Targets（対象ファイルの署名）・Snapshot（全体の状態）・Timestamp（最新性）の4つ アップデート特有の攻撃を阻止: ロールバック・凍結・すり替えを防ぐ 採用状況: CNCF Graduated（PyPI・Sigstore・Docker 等で採用） Sigstore は信頼の起点（Root of Trust）と信頼メタデータ・公開鍵の配信に内部で TUF を利用する。 出典: TUF（The Update Framework）
54. S2C2F (Secure Supply Chain Consumption Framework) OSS を利用する側のリスク低減に特化。Microsoft が原案を策定し、現在は OpenSSF が管理。 つの実践プロセス: 取り込み・スキャン・在庫管理・更新・監査・ポリシー強制・再ビルド・修正を定義 成熟度 L1〜L4: 段階的に整備。L4 は自前構築コストが高く最上位段階 脅威ベースの設計: 実際の攻撃事例に基づき、各要件を SLSA・SSDF 等の他標準とマッピング 8 出典: S2C2F（OpenSSF）
55. OSPS (Open Source Project Security) Baseline OSS メンテナ・プロジェクト向けのセキュリティ基準。OpenSSF が2025年2月に初版を公開。 必須コントロール: 約40〜50の遵守必須（MUST）要件を定義 3段階（L1〜L3）: プロジェクトの規模とリスクに応じて適用 準拠基盤: EU Cyber Resilience Act（CRA）や NIST SSDF への準拠基盤として設計 対象: 個々のビルド成果物ではなく、OSS プロジェクト自体の最低限備えるべき水準を標準化・平準化する 出典: OSPS Baseline（OpenSSF）
56. その他のフレームワーク コンテナのライフサイクル全体（取得〜実行＋可観測性）。実行時保護まで踏み込む（Microsoft） CIS SSC Guide: CI/CD 実装手順のチェックリスト（CIS/Aqua）。 chain-bench で準拠状況を機械監査 CNCF SSC BP v2: 全ロール向けの包括的ベストプラクティス（Source → Materials → Build → Artifacts → Deploy） NIST SSDF（SP 800-218）: セキュア開発プロセスの標準（PO/PS/PW/RV）。米政府調達の必須要件 NIST SP 800-161（C-SCRM）: 調達・サプライヤー管理・全社ガバナンスまで最も包括的。SSDF を内包する OWASP Top 10 CI/CD（攻撃者視点）: CICD-SEC-3 依存悪用 / -4 実行汚染 / -6 認証情報 / -9 完全性検証など。防御側と対比すると どの脅威に有効か確認できる CSSC: 出典: CSSC / CIS SSC Guide / CNCF SSC BP v2 / NIST SSDF・SP 800-161 / OWASP Top 10 CI/CD / デジタル庁 DS-202
57. 目的別の対策 脆弱性対策: SCA・SBOM・VEX・継続スキャン・最小イメージ 2. マルウェア・悪性依存対策: 依存固定・cooldown・依存ファイアウォール・ignore-scripts 3. アカウント・秘密情報の保護: MFA・Trusted Publishing/OIDC・短命トークン・secret scanning 4. ビルド・パイプラインの保護: 最小権限・隔離ビルド・provenance・署名・SHA 固定 5. デプロイ・実行時の検証と保護: デプロイ時検証・admission 制御・eBPF・Egress 制限 6. ガバナンス・プロセス: Policy-as-Code・レビュー強制・SBOM/VEX 運用・インシデント対応 1.
58. 1. 脆弱性対策 既知の脆弱性（CVE）を検知し、修正・リスク低減を図る。 検知 言語依存の既知脆弱性検出（Trivy・Grype・OSV-Scanner・Dependabot） 自社コードの静的解析（SAST）: 依存だけでなく自社が書くコード自体の脆弱性も静的解析で検出（CodeQL・Semgrep） コンテナイメージスキャン（CI + レジストリ自動スキャン） 継続的スキャン: 新規 CVE に追随して保存イメージを再スキャン SCA: OS/ 整理・低減 生成・保持（CycloneDX / SPDX、Syft・cdxgen） 脆弱性 DB の活用（OSV・NVD・GitHub Advisory DB） VEX で悪用可能性を判定（OpenVEX・到達可能性解析） 到達可能性の判定手法: 静的コールグラフ解析（Snyk・Endor Labs）と実行時 eBPF トレースで、脆弱な関数が実際に呼ばれるかを 見極める 最小イメージで CVE の母数を削減（distroless・Wolfi・scratch） Dependabot / Renovate の自動更新で、修正までの時間（MTTR）を短縮 SBOM 出典: Trivy / OSV / CycloneDX・SPDX / OpenVEX / Renovate
59. 2. マルウェア・悪性依存対策（1/2） 取り込み前の遅延・検証・遮断と、取り込み後の動的検知を多層で組み合わせる。 取り込み対象の決定論的固定 で推移的依存まで固定、イメージは digest でピン留め CI は完全再現インストール（ npm ci ・ --frozen-lockfile ） cooldown（ minimumReleaseAge ・ min-release-age ・ npmMinimalAgeGate 等） lockfile 差分の明示的レビュー lockfile 侵入経路の遮断 対策（スコープ名・名前予約・レジストリルーティング・index 固定） レジストリプロキシと許可リスト（Artifactory・Verdaccio 等） 依存関係ファイアウォール（取り込み前ブロック） 検疫（Quarantine）→ スキャン通過後に昇格 ライフサイクルスクリプト無効化（npm v12 既定 / --ignore-scripts ・ onlyBuiltDependencies ） typosquatting / dependency confusion 依存ファイアウォールは install 前に停止するため postinstall を発火させない（takumi guard・Nexus Firewall・JFrog Curation 等）
60. 2. マルウェア・悪性依存対策（2/2） 信頼性と来歴の検証 署名・provenance の検証（npm provenance・PyPI Trusted Publishing / PEP 740・Sigstore） OSS 健全性評価（採用前）: OpenSSF Scorecard でブランチ保護・レビュー・署名リリース・依存ピン留め等を0〜10で可視化 deps.dev・OpenSSF Criticality Score で比較・選定 メンテナ健全性・bus factor 単独メンテナ・保守停止・後継者不在は乗っ取り/権限譲渡リスク大（xz Utils・event-stream） リリース頻度・CVE 対応速度・コントリビューター分散を確認し、代替候補や重点監視を検討 悪性挙動の検知 ・ ・ で難読化・不審通信・資格情報アクセスを早期検知 OSV / GitHub Advisory DB の既知マルウェアと照合し自動遮断 Socket Phylum Endor Labs 出典: pnpm supply chain security / PyPI Trusted Publishing・PEP 740 / OpenSSF Scorecard / deps.dev / OSV
61. 3. アカウント・秘密情報の保護 の乗っ取り、Shai-Hulud のトークン窃取、tj-actions の CI シークレット漏洩の共通原因は「認証情報の奪取・不正 利用」。 認証情報を奪われない・持たない axios の厳格義務化（passkey/WebAuthn・FIDO2。SMS/TOTP を過信しない） Trusted Publishing / OIDC パブリッシュへ移行（短命トークン＋provenance 自動生成） 静的鍵を保存しない OIDC 連携（GitHub Actions × AWS/GCP/Azure） トークン権限の最小化・有効期限・ローテーション・即時失効（fine-grained PAT・ GITHUB_TOKEN の permissions 最小化） MFA 漏らさない・被害を局所化 と Push Protection（gitleaks・TruffleHog） シークレット集中管理とログのマスキング（Vault・Secrets Manager） アカウント公私分離・専用 CI アイデンティティ SSO/IdP 統合（SAML・条件付きアクセス・退職時の一括失効） JIT アクセス・リスクベース認証 ソーシャルエンジニアリング対策（別チャネル本人確認・複数人承認） Secret Scanning 出典: npm Trusted Publishers / GitHub Actions OIDC / GITHUB_TOKEN permissions / GitHub secret scanning push protection
62. 4. ビルド・パイプラインの保護（1/3） ・ ・ が突いた「成果物の組み立て工程」の不変性・完全性を守る。 権限とアイデンティティの最小化 SolarWinds tj-actions TanStack ビルド用 SA・OIDC 実行 ID を最小権限に（発行対象をリポジトリ/ブランチ/環境で限定） ビルドとデプロイを完全分離（成功が自動でデプロイ権限に繋がらない） ビルド環境の分離・無菌化 環境隔離・使い捨てランナー・Hermetic Build（SLSA Build L3） ephemeral セルフホストランナーで状態を残さない Reproducible Build の検証（bit-for-bit 一致）。環境の隔離だけでなくビルド処理の決定論化（ SOURCE_DATE_EPOCH ・順序正規化・ 乱数シード固定）が必要
63. 4. ビルド・パイプラインの保護（2/3） provenance の生成と暗号検証 自動生成 → 署名して attestation 化（SLSA / in-toto / GitHub artifact attestations） in-toto Attestation Framework（Statement／Predicate）が共通フォーマットで、SLSA provenance・SBOM・VEX はその Predicate 成果物・イメージへ暗号署名（ cosign ・Sigstore キーレス・Rekor 記録） provenance 依存・パイプライン定義の固定・保護 ・依存をコミット SHA/digest で固定（immutable actions） ワークフロー定義を CODEOWNERS・ブランチ保護で守る コミット署名の現代化: GPG に加え SSH 署名や Sigstore/gitsign のキーレス署名、ブランチ保護に代わる GitHub Repository Rulesets で組織一括強制 重要変更に電子署名＋複数人承認（NSA/CISA 準拠） Action 出典: SLSA Build Levels / Sigstore・cosign / GitHub Artifact Attestations / in-toto
64. 4. ビルド・パイプラインの保護（3/3） 未検証入力・トリガーの制御 防止: 未検証 PR を特権コンテキストで checkout・実行しない。 pull_request_target を安全に定義しフォークにシークレッ ト/書き込み権限を渡さない CI ワークフロー定義の静的解析: .github/workflows/* を zizmor・actionlint で解析し、 GITHUB_TOKEN 過剰権限や pull_request_target の不備を検出（PPE 防御） ビルドキャッシュ汚染防止: ブランチ・実行スコープで分離 PPE 実行時ネットワーク制御・挙動監視 制限（承認ドメイン/IP のみ。プロキシ・FW・DNS フィルタ・NetworkPolicy） eBPF でランナー挙動をカーネルレベル監視（Harden-Runner・Takumi Runner・cicd-sensor） tj-actions は Egress 異常検知で発見された Egress も対象 等も外部モジュール/プロバイダーを広範な権限で実行する。プロバイダー固定＋チェックサム（ .terraform.lock.hcl ）、 の最小権限分離、tfstate 暗号化、差分レビュー強制＋Policy-as-Code（OPA/Conftest・Checkov・Trivy）。 IaC : Terraform plan/apply 出典: StepSecurity Harden-Runner / Takumi Runner / cicd-sensor / Terraform Lock File / Checkov
65. 5. デプロイ・実行時の検証と保護（1/3） ビルドで生成した署名・provenance をデプロイ時に検証し、実行時の不正動作を監視・遮断する。 デプロイ前検証・ポリシー強制 ・署名の検証（ cosign verify ・ slsa-verifier ） 検証ルールを明示定義（attestation 種別・SLSA レベル・信頼アテスター・ソース URI/ワークフローの完全一致） アドミッション制御（Sigstore policy-controller・Kyverno verifyImages ・OPA/Gatekeeper） Binary Authorization（Cloud Run/GKE・AWS Signer） 正規レジストリ限定＋digest ピン留め リリース管理・段階プロモーション・手動承認・ロールバック（Cloud Deploy・Argo CD） provenance
66. 5. デプロイ・実行時の検証と保護（2/3） 実行時の保護・動的監視 で syscall・プロセス・通信を監視・遮断（Falco・Tetragon） Egress 制限・NetworkPolicy（Cilium・FQDN ベース） 実行 ID の最小権限・Workload Identity（GKE WI・EKS Pod Identity・SPIFFE/SPIRE） イミュータブル・読み取り専用 FS・非 root・Capability 剥奪・ allowPrivilegeEscalation: false 設定ドリフト検知（Argo CD/Flux・digest 照合） eBPF 出典: Sigstore cosign / Kyverno / GKE Binary Authorization / Falco / Kubernetes Network Policies
67. 5. デプロイ・実行時の検証と保護（3/3） 侵害が正規のデプロイ経路を通って侵入する前提で、クラウド基盤側で被害を局所化する。短命資格情報も、攻撃者が足場を確立し 資格情報を再取得できれば完全な防御にならない。 環境隔離とガードレール マルチアカウント/プロジェクトで本番・ステージング・開発を物理分離（横展開の遮断） 予防的ガードレール（組織ポリシー・SCP・Azure Policy）で未承認サービス制限・MFA 強制・監査ログ無効化禁止・公開制限 管理プレーンの検知 コントロールプレーン監査ログをリアルタイム解析（Cloud Audit Logs・CloudTrail）: 異常リージョン・多数の認証失敗・新規 API キー発行を検知 コスト異常検知・予算アラート: マイニング等はコスト高騰として先に顕在化する 出典: Google Cloud Organization Policy / AWS Organizations SCP
68. 6. ガバナンス・プロセス 各技術施策を一時的に終わらせず、組織的に継続運用・改善する構造を確立する。 機械的強制・透明化 （ ・ 。ポリシー自体もバージョン管理・レビュー・テスト） コードレビューの厳格強制（保護ブランチ・必須レビュー数・CODEOWNERS） 改ざん耐性のある操作監査ログの保持 SBOM 全社運用（新規 CVE で影響成果物を即特定） VEX 運用の標準化（OpenVEX・CSAF VEX） リスクベース優先順位（CVSS・EPSS・CISA KEV・到達可能性） Policy-as-Code OPA/Rego Kyverno 調達・教育・改善 サプライヤー評価・調達管理（C-SCRM、NIST SP 800-161 準拠） 開発者・運用者への継続的な教育訓練 インシデント対応プレイブック（provenance/SBOM で影響特定→失効・差替・鍵ローテ・隔離） 成熟度モデルで定期評価・段階的改善（SSDF・SLSA・S2C2F） 出典: CISA KEV / EPSS / NIST SP 800-161r1（C-SCRM）
69. 脅威と対策のマッピング 分類 脅威 脆弱性 既知の CVE マルウェア・ 悪性依存 3. アカウン ト・秘密情報 4. ビルド・パ イプライン 5. デプロイ・ 実行時 悪性バージョン公開・ typosquatting・confusion ガバナンス 各対策の継続運用・改善 1. 2. 6. なりすまし・認証情報窃取 ・ビルド改ざん・キャッシュ 汚染 未検証デプロイ・実行時の不正動 作 PPE 代表的な対策 SCA・SBOM・VEX・継続スキャン・最小イ メージ・自動更新 決定論的固定・cooldown・依存 FW・ Scorecard・ignore-scripts MFA・Trusted Publishing/OIDC・短命トーク ン・Secret Scanning 最小権限・隔離ビルド（L3）・provenance・ 署名・SHA 固定・eBPF 事前検証・Binary Auth・admission・eBPF・ Egress・環境分離 Policy-as-Code・レビュー強制・SBOM/VEX 運用・プレイブック 事例・演習 ・ Log4Shell / 01 07 ・ ・ Shai-Hulud axios / 03 08 ・ axios tj-actions / 04 ・ SolarWinds TanStack / ・ ・ 02 04 06 ・ ・ TanStack / 05 10 11 09 / 対策選定の観点
70. ベンダー・エコシステム側の対応（1/2） 年 月時点。自社で実装する対策ではなく、前提として活用できる外部プラットフォームの動向。 2026 8 （待機期間）の普及: pnpm・npm・Yarn・Bun が最小リリース経過期間（ min-release-age 等）に対応。公開直後のバ ージョンを一定期間インストール対象から外し、悪性バージョンを時間差で回避（axios のような公開直後を狙う攻撃に有効） npm の認証・公開経路の強化: GitHub の「より安全な npm サプライチェーン計画」 。classic トークン失効・FIDO ベース MFA 強 制・デフォルトのトークン無効化・Trusted Publishing 拡大。Shai-Hulud のトークン窃取・不正パブリッシュへの直接対策 install スクリプトの既定無効化（npm v12・2026年7月 GA）: preinstall ・ install ・ postinstall 等を既定で実行しな い。実行には allowScripts の明示許可が必要、CI は strict-allow-scripts で未承認をエラーに。install 時スクリプトは 「npm エコシステム最大のコード実行面」 GitHub Actions セキュリティロードマップ: プラットフォーム自体を既定でセキュア化。依存 Action のコミット SHA 完全ロック （推移的依存含む）・Ruleset 保護とスコープ付きシークレット・ランナーのネイティブ Egress ファイアウォール。tj-actions の可変 タグ悪用や CI からのデータ流出に対処 レジストリ・ベンダーによるマルウェア検知: 悪性パッケージをプラットフォーム層で事前遮断。Chainguard Libraries は npm をソ ースから再ビルドして検知、GitHub Advisory Database は OpenSSF malicious-packages の知見を主要エコシステムへ配信 cooldown 出典: cooldowns.dev / GitHub Blog（npm supply chain）/ Socket（npm v12）/ GitHub Actions 2026 Security Roadmap / Chainguard / OpenSSF maliciouspackages
71. ベンダー・エコシステム側の対応（2/2） インストール前の依存ファイアウォール: Socket Firewall 等がパッケージマネージャの通信をプロキシ検査し、ディスク書き込み前 に安全性を評価して遮断。事後スキャンと異なり install 前に止めるため postinstall を発火させない 堅牢化ベースイメージ（Hardened Images）: Docker Hardened Images が2025年末に1,000超を無償公開。最小構成でシェル等を排 除し既知脆弱性をほぼゼロに、非 root・SLSA Build L3・署名付き SBOM/VEX を標準装備。国内は GMO の Takumi Images。 FROM 差し替えで適用（演習07 と同方向） クラウドの取り込み・実行時防御: AWS CodeArtifact の公開直後ブロック（cooldown 相当）・Inspector への Chainguard 再ビルド済 みライブラリ取り込み、Azure Defender for Containers の実行時マルウェア検知など、主要クラウドが取り込み時・実行時の防御を 強化 AI モデル・成果物の改ざん／マルウェア検査: 保護対象が AI モデルへ拡張。OpenSSF Model Signing が Sigstore でモデルの完全 性・来歴を署名/検証、Azure の AI モデルスキャンが pickle 形式等の悪性コードを配信前に検出 AI 起点脆弱性への協調防御: 未公開の脆弱性情報を業界横断で共有し、影響プロジェクトを開示前に修正・配信（Chainguard Athena） 。ネットワーク層のバーチャルパッチも併用 出典: Socket Firewall / Docker Hardened Images / Takumi byGMO / AWS CodeArtifact・Amazon Inspector×Chainguard / Microsoft Defender for Cloud / OpenSSF model-signing / Chainguard Athena
72. 対策選定の観点 原則に加え、選定時に意識すべき観点。 開発フェーズ × 人・プロセス・技術のマトリクスで点検: 技術偏重で人・プロセスが形骸化した構造的課題を抽出する 内製と外部ツールの双方を対象に: CI/CD 基盤・監視エージェント・SaaS 連携も等しく評価。外部ツールの侵害は盲点になりやすい 予防・遮断＋検知＋事後対応を揃える: 事前予防に偏りやすい。すり抜けを捉える検知（実行時監視・Egress 制限）と、事後対応 （影響特定・失効・鍵ローテ・ロールバック）まで一貫させる シフトレフトの徹底: 悪性コード対策は取得時・導入時の予防に最大の重点。 install 直前で止めれば不正実行自体を防げる。下 流ほど被害と対処コストが増える。ただし予防のみでは限界があるため後段の検知・隔離をバックストップに置く リスクベースで優先順位づけ: ベースラインを一律適用したうえで「発生可能性 × 影響度」で評価。費用対効果を勘案し、機密デー タへ最短で到達する経路から着手する
73. 現実的な制約と対応の落とし所（1/2） これまでは「あるべき対策」を網羅的に整理した。実際の導入には制約があり、理想と現実にはギャップがある。限られ た予算・人員・時間で、どこを優先し、どこを落とし所にするかを判断する。 直面する現実的な制約 すべてを一度に導入できない: 予算・人員・時間が有限 網羅的な強制が難しい: レガシー環境・例外運用・新規リポジトリに設定漏れが生じやすい 残余リスクは必ず残る: 予防は不完全（署名/provenance の偽装・ビルド環境侵害・未知のゼロデイ）。発生確率をゼロにはできない 開発生産性とのトレードオフ: 過度な検証・ブロックは摩擦・誤検知・アラート疲れを生み、形骸化や迂回を招く 統制が及ばない領域: 外部 OSS メンテナ・サードパーティ Action・委託先など直接管理できない部分
74. 現実的な制約と対応の落とし所（2/2） 対応の落とし所 共通基盤で一律強制する: 個別設定に委ねると漏れる。レジストリプロキシ・組織ポリシー・アドミッション制御・Policy-as-Code で一括適用（シフトダウン） 効果が高く低コストな基盤対策から: lockfile ＋ digest/SHA ピン留め・cooldown・スクリプト既定無効化・MFA/Trusted Publishing を横断適用。高コスト/文脈依存の対策は段階導入 残余リスクは検知・事後対応をバックストップに（受容も選択肢）: 実行時監視・Egress で捉え、影響特定・失効・ロールバック。 低リスク領域は受容も判断のうち 短期間での網羅を目指さず段階的に: レポートのみ→ブロック、監査→強制。成熟度モデル（SSDF・SLSA・S2C2F）で継続改善
75. 第3章 Google Cloud 環境での演習
76. 演習の題材: FlowPay 架空企業 PayLoad が開発・運用する経費精算サービス「FlowPay」を題材に、CI/CD パイプラインのサプライチェーン対 策を実装する 構成 の経費精算 API（非公開の Cloud Run、frontend からのみアクセス可） frontend — Node.js / Express の Web UI。金額整形を外部 OSS expense-format に依存 pipelines — Cloud Build のビルド / PR チェック / デプロイ定義 backend — Go 出発点 対策導入前の初期状態からスタート 参加者ごとの個別リポジトリで作業（ backend/ ・ frontend/ ・ cloudbuild.yaml がリポジトリ直下に配置）
77. 演習の進め方 モジュール式 各演習は独立。上から順でも、任意の演習からでもよい 各演習は「関連 → 課題 → ヒント → 検証 → 発展」で構成 解答例は solutions/ にあり、動作確認手順まで含む 各演習の資料: chapter3/exercises ポリシーは Google Cloud プロジェクト単位のシングルトンリソースです。全参加者で単一プロジェクトを共有する環境では、ポリシ ー変更がプロジェクト全体へ直ちに反映され、他の参加者の環境にも影響します。監査モードで検証し、演習後は ALWAYS_ALLOW へ戻してください。 Binary Authorization
78. 演習一覧（01〜14） # 演習 # 01 SCA/SBOM 08 演習 公開直後の依存を避ける（cooldown） 09 Policy-as-Code 10 実行時の監視 11 Cloud Deploy 12 Secret Scanning 13 OpenSSF Scorecard 14 攻撃デモのフォレンジック 02 03 04 05 06 07 イメージ digest 固定 依存パッケージの固定（lockfile ＋ npm ci） ビルド SA の最小権限化 provenance ＋ Binary Authorization cosign keyless 署名 frontend の最小イメージ化 で承認付きデプロイ
79. 演習01: SCA/SBOM で依存とイメージをスキャンし、既知の脆弱性と部品構成を可視化 backend（distroless）と frontend（node:22-slim）で検出件数を比較 依存の深層に何が入っているかを把握できないと、悪性パッケージの混入を察知できない Trivy
80. 演習02: イメージ digest 固定 ビルドで参照するイメージを可変タグ（ latest や :1.23 ）ではなく digest（ @sha256:... ）で固定 対象は Dockerfile の FROM 句と cloudbuild.yaml の step name 可読性のためタグ＋digest の併記形式にする はタグ書き換えで悪性コードが引き込まれた事案だが、コミット SHA や digest で固定していた利用者は影響を受けなかった。「可 変タグは後から中身を差し替えられる」という前提への対策。 tj-actions/changed-files
81. 演習03: 依存パッケージの固定（lockfile ＋ npm ci） から npm ci へ変更し、lockfile どおりの依存だけをハッシュ検証込みでインストール 推移的依存の完全固定に有効。Shai-Hulud / axios のような悪性依存の混入経路を塞ぐ 演習02（digest 固定）と同じ「入力を決定論的に固定する」原則を依存側に適用したもの npm install
82. 演習04: ビルド SA の最小権限化 ビルドを実行するサービスアカウント（SA）を、必要最小限のロールに絞る 専用 SA（例: flowpay-build-sa ）を作り、「AR へ push」「ログ書き込み」「ソース読み取り」に対応するロールだけを付与 手動 submit でロールの十分性を確認してから、トリガーの実行 SA を差し替える の GITHUB_TOKEN 最小化に相当する Google Cloud での対策。Shai-Hulud / TanStack のように CI の資格情報が窃取された場合、SA の権 限がそのまま被害範囲になる。 GitHub Actions
83. 演習05: provenance ＋ Binary Authorization 生成側: provenance でビルドに provenance を付与 「どのソースの・どのコミットから・どのビルダーで・どの入力で」この digest になったかを署名付きで追跡（SLSA v0.1 / v1.0） requestedVerifyOption: VERIFIED 検証側: Binary Authorization Cloud Build 製（provenance 付き）イメージだけを Cloud Run がデプロイ時に受け入れる。未検証イメージ（例: nginx）は拒否さ れる 信頼を前提にせず、デプロイ時に検証する Binary Authorization 元する。 はプロジェクト単位のシングルトンポリシー。監査モード（ DRYRUN_AUDIT_LOG_ONLY ）で検証し、演習後は ALWAYS_ALLOW へ復
84. 演習06: cosign keyless 署名 で keyless 署名。長寿命の秘密鍵を持たず、OIDC の身元証明から一時証明書（Fulcio）を得て署名し、Rekor に記録 窃取対象となる鍵を保管しないという根本対策 Sigstore は公開型の透明性ログ。署名者の identity（プロジェクト名を含むビルド用 SA のメールアドレス）が公開される点に、共有環境・本番運用では留意 する。 Rekor
85. 演習07: frontend の最小イメージ化 のベースイメージ（node:22-slim）を distroless / Chainguard などの最小イメージへ置き換える 依存は先行ステップ（ frontend-deps ）で導入済みのため、実行イメージには node_modules をコピーするだけの構成にする 演習01で見た backend（distroless）と frontend の検出件数の差を、frontend 側で縮小する frontend 攻撃対象領域（アタックサーフェス）と既知の脆弱性の検出数を、成果物そのものを小さくすることで削減する。演習01の継続課題。
86. 演習08: 公開直後の依存を避ける（cooldown） レジストリへ公開された直後のバージョンを、一定期間インストール対象から外す npm は .npmrc の min-release-age 、pnpm は minimumReleaseAge で設定 axios の事案のように「公開直後の数時間」を狙う攻撃を、時間差で構造的に回避する
87. 演習09: Policy-as-Code ポリシーを Git 管理し、Terraform / スクリプトで適用 複数アテスターの必須化（正規ビルドの証明＋人手のレビュー承認を AND）などへ拡張 パイプライン定義を書き換えても検証を回避できない構造にする Binary Authorization 演習05 の Binary Authorization をコード化・拡張する続き。プロジェクト単位のシングルトンポリシーのため、監査モードで検証し演習後は ALWAYS_ALLOW へ復元する。
88. 演習10: 実行時の監視 まず「既定のビルドログでは悪性コードの実行挙動が見えない」ことを実機で検証（ postinstall の出力は --foregroundscripts を付けて初めて表示される） 静的検証を回避して侵入した攻撃を、動的なシステム挙動から検知する多層防衛を整理 アウトバウンド通信（Egress）の制御 プロセスメモリ空間の保護（ /proc/<pid>/mem 等） eBPF によるシステムコール・C2 通信の監視 Harden-Runner、cicd-sensor、Cloud Run 標準監視などを導入・比較 Shai-Hulud / TanStack が必要になる。 のように CI ランナー上で悪性コードが実行され資格情報を窃取する挙動は、事前の静的検証だけでは防ぎきれない。実行時の監視
89. 演習11: Cloud Deploy で承認付きデプロイ 「push で Cloud Build が自動デプロイ」する構成を、Cloud Deploy のリリース管理へ移行 本番反映前に手動承認ゲート（ requireApproval: true ）を置く。ロールアウトは PENDING_APPROVAL で停止し、承認して初め てリビジョンが切り替わる 過去リリースへのロールバックも承認を経て実行 ビルドの成功が自動で本番反映に直結しないよう、職務分掌をデプロイ段階で実装する 演習05まで完了していれば、承認後のデプロイが Binary Authorization の検証も通過することまで確認できる。
90. 演習12: Secret Scanning の secret スキャナで、ソースとコンテナイメージから認証情報（API キー・トークン・秘密鍵）の混入を検出 CI（Cloud Build）に組み込み、初期はレポートのみ、慣れたら検出時にビルドを止める品質ゲートにする 検出された認証情報は、削除だけでなく必ず無効化・ローテーションする Trivy
91. 演習13: OpenSSF Scorecard リポジトリのセキュリティ実践（ブランチ保護・レビュー・依存の固定・トークン権限・署名リリース）を 0〜10 で自動評価 依存先 OSS の健全性を把握し、あわせて自リポジトリの弱点も点検する スコアは実践の有無の目安であり、高スコアが安全を保証するわけではない
92. 演習14: 攻撃デモのフォレンジック 攻撃デモの悪性パッケージの挙動を、防御側が取得できる証跡から調査する パイプラインのログ・通信記録（VPC フローログ等）・ランタイム監視で、それぞれ何が見えるか 見えるもの／見えないものを整理する（メタデータアクセスはネットワークログに出ずランタイム監視が要る、送信データの中身は 宛先しか分からない）
93. まとめ 1 脅威を理解し、対策を網羅的に知る 個別の事例や手法の暗記にとどまらず、開発ライフサイクル全体に潜むリスクの構造と、多層防御の全体 像を理解する。 2 企業での対策のアプローチを知り、実務に活かす 理想論ではなく、現実的な制約の中で優先順位を見極め、共通基盤側で安全性を担保する設計・運用の考 え方を身につける。 今後ご自身でプロダクト開発・運用に携わる中で、本講義での学びが役立てば幸いです。
94. ご清聴ありがとうございました ご質問は @kyohmizu まで