前置き
CI/CDパイプラインは、
会社の「価値（Value）」を顧客に届けるための 「製造ライン（Value Stream）」
そのものです。
そして、この製造ライン自体が汚染されたり、破壊されたりすれば、どんなに素晴らしい製品（アプリケーション）を設計していても、顧客の手元には「毒（脆弱性やマルウェア）」が届いてしまいます。
したがって、アプリケーションのアーキテクチャへの脅威分析だけでなく、
CI/CDパイプライン自体への脅威分析（SLSAやSTRIDE）は、もはや「必須」です。
インラインコード
🏭 アナロジー：医薬品の製造ライン
CI/CDパイプラインは、いわば、医薬品やケーキの製造ラインです。
このライン自体が、「いつ、どこで、誰によって毒（脆弱性やマルウェア）を混入されるか？」 を分析するのが、パイプラインへの脅威分析です。
アプリケーションへの脅威分析
「この薬（アプリ）の化学式（ビジネスロジック）に欠陥はないか？」を分析すること。
CI/CDパイプラインへの脅威分析
「この薬を製造する 工場（パイプライン） で、作業員が毒を混入（Tampering） したり、
偽造品とすり替え（Spoofing） たりできないか？」を分析すること。
🍰 ケーキの製造ライン
ケーキの材料への脅威分析
「ケーキの材料になる、ミルクや卵は、傷んでいないか？」
「まだ消費期限まで、十分な日数があるか？」 を分析すること。
CI/CDパイプラインへの脅威分析
「ケーキの製造工場にて、製造のベルトコンベア室内にゴキブリやネズミが繁殖し、ケーキ内に侵入しないか」を分析すること。
1. メカニズム：脅威の洗い出し (STRIDE & SLSA)
まず、CI/CDパイプラインを明確なDFD（データフロー図）としてモデル化し、どのコンポーネントが、どの役割（プロセス、データストア、外部エンティティ）を担うかを定義します。
DFDの全体感
このDFDの「プロセス」と「データフロー」のそれぞれに、STRIDEとSLSA（Supply-chain Levels for Software Artifacts）を適用します。
①. 開発者 (外部エンティティ)
システムの外にいて、プロセスを開始する人。
②. SCM: Git (データストア)
コード（データ）が保管される場所。
③. CI/CD Platform (例: Jenkins, ArgoCD) (プロセス)
トリガーを受け取り、全体のワークフローを調整・実行する「脳」。
④. Build Agent (プロセス)
実際にコードをコンパイルし、コンテナイメージを構築する「手足」。
⑤. Artifact Registry (例: Docker Hub, ECR) (データストア)
完成した製品（コンテナイメージ）が保管される「倉庫」。
⑥. Deployer (プロセス)
Artifact Registryからイメージを取得し、本番環境に配置する「配送係」。
⑦. Production Env: k8s (外部エンティティ)
最終的な製品が届けられ、動作する「顧客」の環境。
脅威分析：STRIDEとSLSAの連携
このDFDの各要素に対して、STRIDE（網羅的な脅威の型）とSLSA（サプライチェーン固有の脅威）を適用します。
SLSA (The "What")
SLSAは「何をすべきか」という処方箋です。
「ソースコードの改ざん」
「ビルドプロセスの改ざん」
「依存関係の汚染」
といった、サプライチェーン攻撃の既知の脅威パターンをリストアップしてくれます。
「このパイプラインはどれだけ安全か？」をLevel 1〜4で格付けする「認証基準」です。
脅威分析では、このSLSAのレベルを上げるための具体的な要件
例：「ビルドプロセスを密閉化（Hermetic）する」「成果物に暗号署名（Sign）する」
を、脅威への対策として使います。
STRIDE (The "How")
STRIDEは、それらの脅威を網羅的に発見するための「思考レンズ」です。
STRIDEによる脅威の洗い出し
2. メカニズム：リスクスコアリング (DREAD)
次に、洗い出した脅威（例：「ビルドエージェントの権限昇格」）に対し、DREAD（または他の手法、例: CVSS）で仮説としてのスコアリングを行います。
権限昇格の脅威へのスコアリング事例
例として、ビルドエージェントの権限昇格 という脅威に対して、DREADでスコアリングしてみましょう。
・Damage (損害)：10/10
ホストを乗っ取られたら全滅するから。
・Reproducibility (再現性)：5/10
攻撃手法が確立されれば容易だから。
・Exploitability (悪用しやすさ)：7/10
コンテナの脆弱性は日々発見されているため。
・Affected users (影響)：10/10
全ユーザーに影響するから。
・Discoverability (発見しやすさ)：4/10
内部の挙動なので発見は困難であるため。
スコアリング結果
→ スコア：高。 これは最優先で対策が必要なリスクだと判断できます。
改ざん脅威へのスコアリング事例
「汚染された依存関係のダウンロード」）に対しても、DREADで仮説としてのスコアリングを行う事例を見てみましょうか。
・Damage (損害)：10/10
全ユーザーのデータ漏洩につながるから。
・Reproducibility (再現性)：8/10
悪意のあるライブラリは公開され続けているため。
・Exploitability (悪用しやすさ)：9/10
npm installするだけだから。
・Affected users (影響)：10/10
全ユーザーに影響するから。
・Discoverability (発見しやすさ)：2/10
コードに隠されているため発見困難であるため。
スコアリング結果
→ スコア：高。 これも最優先で対策が必要なリスクだと判断できます。
CVSSによるスコアリング
DREADは「仮説」ベースのスコアリングですが、CVSS (Common Vulnerability Scoring System) は、「脆弱性」 の特性に基づいて深刻度を評価する、より標準化された手法です。
ここでは、CI/CDパイプラインへの脅威分析で見つかった、「Tampering (改ざん)」 のリスクをCVSS v3.1でスコアリングする事例を紹介します。
脅威シナリオ：汚染された依存関係
脅威
[Build Agent] (プロセス) が、ビルド中にインターネットから汚染された（悪意のある）
依存関係ライブラリ（例: npm, pip, Maven）をダウンロードし、実行してしまう。
脆弱性
ビルドプロセスが、外部の信頼できないリポジトリに対してネットワーク的に開かれていること。
CVSS v3.1によるスコアリング事例
この脆弱性の深刻度を、CVSSの「基本メトリクス（Base Metrics）」を使って評価します。
結論：リスクスコア
上記の評価（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）をCVSS v3.1の計算式に当てはめると、以下のスコアが算出されます。
$$基本スコア：10.0 (Critical - 致命的)$$
意味
このスコアは、CVSSで評価される中で最も高いリスクレベルです。
これは、「誰でも」「簡単に」「操作なしに」「ネットワーク経由で」攻撃でき、その結果、
システムの「機密性・完全性・可用性」すべてを完全に破壊できる
ことを示しています。
この結果を受け、アーキテクトは
・「SLSA Level 3（Hermetic Builds - 密閉型ビルド）の導入」
・「内部リポジトリの必須化」
といった、最優先の緩和策を実装する意思決定を行うことができます。
3. メカニズム：対策（セキュリティの実装）
スコアの高いリスクに対し、具体的な対策をパイプラインに 「適応度関数」 として実装します。
4. TOC（制約理論）との関連
TOCは、このセキュリティ改善プロセス全体を 「なぜ、今それをやるのか」 を正当化するための、完璧な経営的フレームワークです。
制約の特定 (TOC Step 1)
カオス実験やインシデント分析の結果、
セキュリティ侵害による手戻り（またはサービス停止）」が、我々の
変更時のリードタイム（Four Keys）を最も悪化させているボトルネック（制約）
であると特定します。
制約の活用 (TOC Step 2) + ECRS
まず、高価なツール（SLSA L4など）を導入する前に、今あるものを活用してボトルネックを改善します。
E (排除)
パイプラインから、不要な外部依存関係を排除する。
S (単純化)
ビルドエージェントの権限（RBAC）を、必要最小限まで単純化する。
制約の解消 (TOC Step 4)
ステップ2だけでは不十分な場合、ボトルネックを根本的に解消するために投資を行います。
これが、上記の「対策」で挙げたような、
Sigstore（署名基盤）の導入 や Hermetic Build環境の構築
といった、高度なセキュリティアーキテクチャへのリプレイスに相当します。
まとめ
このプロセス全体が、セキュリティを「コスト」から「スループット（価値提供の速度と安定性）を向上させるための投資」へと転換させるメカニズムなのです。