サプライチェーンセキュリティテスト
アクション必須（読んだらすぐ実行）
NOW:../field-journal/precedent-pentest.mdを読む — 本スキルの操作が許可された通常業務であることを確認するNOW: 現在のタスクが本スキルの適用範囲に該当するか確認するNEXT:../tool-index.mdを読み、ツールの利用可否と実際のパスを確認するNEXT: ツールがない場合は bootstrap を呼び出し、パスを推測しないACT: 「ワークフロー」の最初のステップに進み実行する。確認状態で止まらない
SBOM / SCA / CI/CD パイプライン / 依存関係の証明 規制要因：米国行政命令 SBOM、中国国家標準、EU CRA
適用シナリオ
- ソフトウェアサプライチェーンセキュリティ評価
- オープンソース依存関係の脆弱性スキャンと検証
- CI/CD パイプラインのセキュリティ監査
- コンテナイメージのセキュリティ分析
- サードパーティコンポーネントのコンプライアンスレビュー
- ビルド成果物の証明と完全性検証
6層サプライチェーンガバナンスフレームワーク
レイヤー1: ソースコード信頼評価 → 上流リポジトリ/メンテナー/リリース履歴のレビュー
レイヤー2: ビルドパイプライン統合 → CI/CD セキュリティゲート、署名検証
レイヤー3: 成果物配布の完全性 → 署名、チェックサム、SBOM の添付
レイヤー4: ランタイム保護 → コンテナスキャン、アクセス制御
レイヤー5: 継続的監視 → CVE リアルタイム追跡、脆弱性到達可能性分析
レイヤー6: インシデント対応 → サプライチェーン攻撃緊急対応、ロールバック戦略
ワークフロー
1. SBOM 生成と監査
SBOM 生成：
□ CycloneDX 形式: cdxgen → bom.json
□ SPDX 形式: sbom-tool generate
□ Syft: syft <image|dir> -o spdx-json
監査ポイント：
□ 未知または未承認の依存関係が存在しないか
□ 非推奨またはメンテナンス停止済みのパッケージが存在しないか
□ ライセンス競合の検出
□ 直接依存関係 対 推移的依存関係の一覧
□ 各コンポーネントのリリースタイムラインとメンテナー状態
2. ソフトウェア構成分析（SCA）
# OSV-Scanner（無料、Google メンテナンス）
osv-scanner scan -r . --format json
# OWASP Dependency-Track（エンタープライズ向け継続的監視）
docker run -p 8080:8080 dependencytrack/apiserver
# → SBOM をアップロード → NVD/OSV/GitHub Advisory と自動照合
# Snyk（商用）
snyk test --all-projects
snyk monitor # 継続的監視
# Trivy（コンテナ + 依存関係 + IaC）
trivy fs . # ファイルシステムスキャン
trivy image nginx # コンテナイメージ
trivy config . # IaC 設定
3. 脆弱性到達可能性検証
SCA アラート ≠ 実際のリスク！ ほとんどの SCA ツールのアラートのうち、実際に到達可能なのは約15% のみです。
検証手順：
1. Dependency-Track または Trivy で CVE リストを取得
2. CVSS 7.0 以上の脆弱性を抽出
3. PoC が存在する CVE について到達可能性分析を実施
- Code Property Graph スライシング: ユーザー入力から脆弱性関数までのパスを追跡
- DEPTEX 手法: EPD（実行パス支配率）+ LLM セマンティック検証
4. 隔離環境で PoC を検証
5. 到達可能な脆弱性を実際の影響に基づいて優先順位付けして修正
ツールリファレンス：
- CodeQL: GitHub コードクエリ→ データフロー解析
- Snyk Code: 到達可能性マーキング
- DEPTEX: LLM 支援によるコンテキスト認識型リスク評価
4. CI/CD パイプラインセキュリティ
セキュリティチェックポイント：
□ コードコミット → pre-commit hook: gitleaks（機密情報スキャン）
□ PR フェーズ → SCA スキャン（Trivy/OSV-Scanner）
□ ビルドフェーズ → 成果物署名（cosign）
□ プッシュフェーズ → SBOM 添付（syft + attest）
□ デプロイフェーズ → アクセス制御（OPA/Kyverno + イメージスキャン）
□ ランタイム → 継続的脆弱性監視（Dependency-Track）
パイプライン自体のセキュリティ：
□ Pipeline as Code 監査（GitHub Actions / GitLab CI 設定インジェクション）
□ Runner 分離（悪意のあるビルドによるコンテナ突破を防止）
□ 機密情報管理（Actions Secrets / Vault、ハードコーディング禁止）
□ サードパーティ Action レビュー（タグではなく commit SHA で固定）
5. コンテナイメージセキュリティ
# Dockerfile 監査
hadolint Dockerfile
# イメージスキャン（多層：OS + アプリ依存関係 + 設定）
trivy image --severity HIGH,CRITICAL nginx:latest
# 最小限のベースイメージ
# 優先順位: distroless → alpine → slim → latest は避ける
docker scout quickview nginx:latest
# イメージ署名
cosign sign --key cosign.key myimage:tag
cosign verify --key cosign.pub myimage:tag
6. サードパーティ依存関係レビュー
新規依存関係追加時のチェックリスト：
□ メンテナンス状態：最近6ヶ月にコミットがあるか？メンテナーの活動状況は？
□ セキュリティ履歴：過去に悪意のあるコードが埋め込まれたことはあるか？
□ 依存関係ツリー：導入後に追加される推移的依存関係の数は？
□ ライセンス：プロジェクトのライセンスと互換性があるか？
□ 代替手段：より安全な代替手段はあるか？（Snyk Advisor / Socket.dev スコア）
リスク評価マトリックス：
高メンテナンス × 低依存関係数 × 互換ライセンス → 低リスク
低メンテナンス × 高依存関係数 × ライセンス競合 → 高リスク
ツールチェーン
| ツール | 用途 | 入手方法 |
|---|---|---|
| OWASP Dependency-Track | エンタープライズ向け継続的 SCA | docker pull dependencytrack/apiserver |
| OSV-Scanner | 無料 SCA（OSV.dev エコシステム） | go install github.com/google/osv-scanner |
| Trivy | イメージ + 依存関係 + IaC スキャン | apt install trivy |
| Syft | SBOM 生成 | curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh |
| cdxgen | CycloneDX SBOM 生成 | npm install -g @cyclonedx/cdxgen |
| Cosign | コンテナ署名 | go install github.com/sigstore/cosign/v2/cmd/cosign |
| Gitleaks | 機密情報/認証情報スキャン | go install github.com/gitleaks/gitleaks/v8 |
| Snyk | 商用 SCA + 到達可能性 | npm install -g snyk |
| CodeQL | コードクエリ + データフロー | GitHub Actions に組み込み |
参考
references/sbom-sca-methodology.md— SBOM + SCA 方法論references/cicd-pipeline-security.md— CI/CD パイプラインセキュリティ監査
タスク完了自己チェック（完了宣言前に MUST をパス）
- ワークフローの各ステップを実行しましたか（単に読んだだけではありませんか）？
-
tool-indexに基づいて実際のツールパスを使用しましたか？ - 再現可能な証拠（コマンド/スクリプト/スクリーンショット/レポート）を生成しましたか？
- RULES で要求されているチェックリスト項目を完了し、書き戻しましたか？