Supply Chain Security

サプライチェーンセキュリティ

目的

Claude が、ソフトウェアサプライチェーンをエンドツーエンドで評価し、強化できるようにします。具体的には、プロジェクトが何に依存しているか、それらの依存関係がどのように取り込まれたか、どのようにビルドされたか、そして下流の利用者がその成果物をどのように信頼できるかを評価します。これはスキル 02（脆弱性スキャナー）を補完するものです。スキル 02 が「これは既知の脆弱なバージョンか」と問うのに対し、このスキルは「この依存関係、ビルド、またはパイプラインは、そもそも信頼できるものか」と問います。

---

有効化のトリガー

次のような質問があった場合に、このスキルが有効になります。

• SBOM（ソフトウェア部品表）の生成、検証、分析（CycloneDX、SPDX）
• 依存関係の混乱、タイポスクワッティング、悪意のあるパッケージや侵害されたパッケージ（npm、PyPI、RubyGems、crates.io、Maven、Go モジュール）
• 疑わしい postinstall／preinstall スクリプトや、その他のパッケージライフサイクルフック
• CI/CD パイプラインのセキュリティ — GitHub Actions、GitLab CI、Jenkins の強化
• 成果物の署名、来歴、証明 — SLSA レベル、in-toto、Sigstore/cosign、npm provenance
• ビルドの再現性、または「このビルドは公開済みのものと一致するか」という質問
• 新しい依存関係の導入時における、ベンダー／オープンソースコンポーネントのリスク
• 上流のパッケージの侵害、メンテナーアカウントの乗っ取り、または改ざんされたビルドパイプラインに関するインシデント

---

前提条件

pip install pyyaml requests

拡張用の任意ツール：

• syft ／ cyclonedx-py ／ cdxgen — SBOM の生成（CycloneDX／SPDX）
• grype ／ osv-scanner — SBOM に基づく脆弱性の照合（スキル 02 と連携）
• cosign — 成果物／イメージの署名と検証（Sigstore）
• slsa-verifier — SLSA 来歴証明の検証
• scorecard（OpenSSF）— GitHub リポジトリのサプライチェーンリスクを自動スコアリング

---

主な機能

1. SBOM の生成と分析

ユーザーが SBOM の生成またはレビューを依頼した場合：

1. プロジェクトで使用されているエコシステムを特定し（以下のマニフェスト一覧を参照）、適切なツール（syft dir:. -o cyclonedx-json、cyclonedx-py、または言語固有の同等ツール）で CycloneDX または SPDX の SBOM を生成します。ツールを使用できない場合は、ロックファイルからコンポーネントの一覧を手動で作成します。
2. 各コンポーネントについて、名前、バージョン、エコシステム／PURL、宣言されたライセンス、（入手可能な場合は）既知の脆弱性を記録します。
3. スキル 02 の脆弱性スキャンと照合し、SBOM と VEX を組み合わせたビューを作成します。影響を受けるコンポーネントと、そのうち実際にコード内から到達可能なものを特定します。
4. ソースリポジトリが見つからないコンポーネント、初回公開日が異常に新しい一方でダウンロード数が急増しているコンポーネント、またはプロジェクトの方針に反するライセンス（例：プロプライエタリ製品におけるコピーレフト）を持つコンポーネントに警告を出します。

2. 依存関係の混乱とタイポスクワッティングの検出

ユーザーが悪意のあるパッケージや紛らわしいパッケージがないか依存関係を監査するよう依頼した場合：

1. タイポスクワッティング — 宣言されたパッケージ名を、同じエコシステムの広く知られた人気パッケージと比較し、よく似た名前（編集距離、ハイフンの追加／削除、区切り文字の入れ替え、同形異字文字）を探します。
2. 依存関係の混乱 — 内部／プライベートパッケージ名について、実際にスコープ指定（npm の @org/pkg）されていること、または同名の公開パッケージによる乗っ取りを防げることを確認します。スコープ指定やプライベートレジストリの固定なしに参照されている内部パッケージには警告を出します。
3. レジストリ上の存在とメタデータ — パッケージが宣言されたレジストリに現在も存在することを確認し、メンテナーの突然の変更、バージョンの大幅な跳ね上がり、長期間公開されているパッケージの README が空またはほぼ空であることは、警告に値する兆候として扱います。
4. 自動化できる部分（タイポスクワッティングの距離、可変バージョン、ロックファイルの欠如、ライフサイクルスクリプトに関する危険信号）には scripts/supply_chain_auditor.py を使用します。スクリプトがわずかに似た名前として検出したものは、侵害の証拠とみなさず、人間の判断を加えます。

3. 悪意のあるパッケージの兆候

特定のパッケージ（新しい依存関係、またはフラグが立てられたパッケージ）の侵害を調査する場合：

深刻度の高い順に確認します。

• ライフサイクルスクリプトの悪用 — リモートコードを取得して実行する、base64のデータをデコードする、または環境変数（NPM_TOKEN、GITHUB_TOKEN、クラウドシークレット）から CI／レジストリの認証情報を読み取る preinstall／install／postinstall／prepare フック。
• 難読化 — 難読化されたソースコードを含める正当な理由がないパッケージ内の、圧縮／パック済みコード（ほとんどのライブラリにその必要はありません）。
• ネットワーク経由の情報流出 — 無関係に見えるコードに埋め込まれた、生の IP リテラルや見慣れないドメインへのアウトバウンド通信、または DNS ベースの情報流出パターン。
• バージョンと動作の不一致 — パッチレベルのバージョン更新で、依存関係を変更する、インストールスクリプトを追加する、または無関係なファイルに手を加える場合（変更履歴だけでなく、バージョン間の差分を比較してください）。

4. CI/CD パイプラインの強化

ビルド／デプロイのパイプラインのレビューを依頼された場合：

GitHub Actions のチェックリスト

[ ] Third-party actions pinned to a full commit SHA, not a mutable tag/branch
[ ] Workflow declares explicit top-level `permissions:` (default is broad without it)
[ ] pull_request_target is never combined with checkout of PR head + code execution
[ ] Secrets are scoped to the job/environment that needs them, not global
[ ] Self-hosted runners are not used for public-repo PR workflows (arbitrary code execution risk)
[ ] Reusable/composite actions from third parties are reviewed like any other dependency
[ ] Build artifacts are published with provenance (see below), not just uploaded raw

一般的な CI/CD チェックリスト（すべてのプラットフォーム）

[ ] Build environment is ephemeral / reproducible, not a long-lived hand-configured box
[ ] Dependency resolution uses lockfiles, not floating ranges, at build time
[ ] Credentials for package publishing require MFA / short-lived tokens, not long-lived static secrets
[ ] Branch protection requires review before merge to the branch that triggers release builds
[ ] Release/publish step is a distinct, auditable job — not implicit in every merge to main

scripts/supply_chain_auditor.py --project-dir . を使用すると、.github/workflows/ 全体で、バージョンが固定されていない GitHub Actions と permissions: ブロックの欠落を自動的に検出できます。

5. アーティファクトの来歴と署名

アーティファクトの出所の証明について質問された場合：

1. SLSA — SLSA ビルドレベルを評価するか、目標として設定します（L1：来歴が存在する。L2：来歴が認証され、ホスト型ビルドサービスによって生成される。L3：ビルドスクリプト自体による改ざんも防ぐ、強化された隔離型ビルドプラットフォーム）。現在のレベルと、次のレベルに必要なことを明示します。
2. Sigstore/cosign — コンテナイメージとリリースアーティファクトには、キーレス署名（OIDC に紐付けられ、漏えいの恐れがある長期利用の秘密鍵を必要としない）を推奨します。公開時に cosign sign を実行し、利用／デプロイ時に cosign verify を実行します。
3. in-toto — 複数ステップのビルドパイプラインでは、最終アーティファクトだけでなく、完全な管理連鎖を検証できるよう、各ステップでアテステーションを作成することを推奨します。
4. npm provenance（npm publish --provenance）— CI から公開するすべての npm パッケージで、利用者が申告されたソースコミット／ワークフローからビルドされたことを検証できるよう、使用を推奨します。

6. サードパーティおよびベンダーコンポーネントのリスク

新しい依存関係は、Skill 19 で新しいベンダーを扱うのと同じように扱います。保守状況を示す情報（最近のコミット、迅速な課題対応、複数のメンテナーがいること。単独メンテナーのパッケージはバス係数のリスクです）、ライセンスの互換性、そして利用する機能がわずかなのに、サイズが大きく監査頻度の低い推移的依存関係ツリーを取り込んでいないかを確認します。

---

出力テンプレート

# Supply Chain Security Assessment
**Target:** [Repository/Project]
**Date:** [Date]
**Scope:** [Dependencies / CI-CD pipeline / Build artifacts / All]

---

## Executive Summary
[2-3 sentences: SBOM component count, findings by severity, top risk]

## Finding Summary
| Severity | Count | Examples |
|----------|-------|----------|
| Critical | 1 | Postinstall script executes remote payload |
| High     | 3 | Typosquatted package `lodahs`, unpinned Action `actions/checkout@v4` |
| Medium   | 5 | Floating version ranges, missing workflow `permissions:` |
| Low      | 2 | Range-pinned (`^`/`~`) dependency versions |

## Findings Detail

### CRITICAL-01: [Finding Title]
**Component:** [package@version] | **Ecosystem:** [npm/PyPI/...]
**Evidence:** [exact script/pattern/diff observed]
**Risk:** [what an attacker gains if this is exploited]
**Remediation:** [pin version / remove script / replace dependency / etc.]

---

## SBOM Summary
| Component | Version | Ecosystem | License | Known CVEs |
|-----------|---------|-----------|---------|------------|

## Provenance Status
| Artifact | SLSA Level | Signed (cosign) | Attestation |
|----------|-----------|------------------|-------------|

## Remediation Roadmap
| Priority | Action | Effort | Risk Reduction |
|----------|--------|--------|-----------------|

---

スクリプトリファレンス

supply_chain_auditor.py

# Static scan: typosquatting, floating versions, risky lifecycle scripts, unpinned Actions
python scripts/supply_chain_auditor.py --project-dir . --output audit.json

# Also verify each dependency exists on its public registry (adds network calls)
python scripts/supply_chain_auditor.py --project-dir . --check-registry --output audit.json

package.json（npm）、requirements.txt（PyPI）、Cargo.toml（crates.io）、go.mod（Go）のマニフェストを対象に、ロックファイルの有無、タイポスクワッティング、バージョンの未固定（npm／PyPI）、リスクのあるライフサイクルスクリプト（npm）を確認します。また、.github/workflows/ 以下のすべてのワークフローも確認します。検出結果は、ヒューリスティックによる類似項目や設定の不備であり、侵害の証拠ではありません。フラグが立てられたパッケージを悪意のあるものと判断する前に、必ず手作業で確認してください。

---

スキル連携

条件	次のスキル
SBOM に既知の脆弱性を持つバージョンが示されている	→ CVSS／EPSS／KEV のスコアリングには Skill 02（脆弱性スキャナー）
悪意のあるパッケージが確認された	→ ペイロードの静的／動的解析には Skill 05（マルウェア解析）
本番環境でパイプラインの侵害が疑われる	→ Skill 07（インシデント対応）
パイプラインがクラウド／K8s 環境で実行されている	→ CI/CD ランナーとワークロード ID のレビューには Skill 10（クラウドセキュリティ）
コンプライアンスへのマッピングが必要（例：SSDF、NIST 800-218）	→ Skill 19（GRC とコンプライアンス）
レッドチーム活動中に発見された	← Skill 14（レッドチーム運用）

---

参考資料

• SLSA — ソフトウェア成果物のサプライチェーンレベル
• Sigstore · cosign
• in-toto
• CycloneDX · SPDX
• OpenSSF スコアカード
• NIST SP 800-218 — セキュアソフトウェア開発フレームワーク（SSDF）
• OWASP ソフトウェアコンポーネント検証標準（SCVS）
• npm の来歴証明