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 来源证明
• 构建可复现性，或“此构建是否与已发布内容一致”之类的问题
• 在引入新依赖时评估供应商／开源组件风险
• 涉及上游软件包遭入侵、维护者账号被接管或构建流水线遭投毒的事件

---

前置条件

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. 识别项目所用的生态系统（参见下方清单文件对照表），并使用适当的工具生成 CycloneDX 或 SPDX SBOM（syft dir:. -o cyclonedx-json、cyclonedx-py 或语言原生工具）——或者，在没有工具的情况下，直接根据锁文件手动列出组件。
2. 对每个组件，记录：名称、版本、生态系统／PURL、声明的许可证，以及（如果有）已知漏洞。
3. 与技能 02 的漏洞扫描结果交叉比对，提供 SBOM+VEX 综合视图：哪些组件受到影响，以及代码中哪些受影响组件实际可达。
4. 标记无法找到源代码仓库的组件、首次发布距今异常短却突然拥有大量下载量的组件，或许可证与项目政策冲突的组件（例如，在专有产品中使用 copyleft 许可证）。

2. 依赖混淆与仿冒拼写检测

当用户要求审计依赖中是否存在恶意或易混淆的软件包时：

1. 仿冒拼写 — 将声明的软件包名称与同一生态系统中的知名热门软件包进行比对，查找名称近似的情况（编辑距离、增删连字符、分隔符互换、同形异义字符）。
2. 依赖混淆 — 对任何内部／私有软件包名称，确认其确实有作用域限定（npm @org/pkg），或以其他方式确保不会被同名的公开软件包冒充；标记任何未指定作用域或未锁定私有注册表的内部软件包引用。
3. 注册表存在性与元数据 — 验证软件包在其声明的注册表中仍然存在；对于长期存在的软件包，维护者突然变更、版本号大幅跳升或 README 为空／近乎为空，都应视为值得标记的信号。
4. 使用 scripts/supply_chain_auditor.py 执行可自动化的检查（仿冒拼写距离、浮动版本、缺少锁文件、生命周期脚本风险信号）；对脚本标记为名称近似的情况运用人工判断，不要将命中视为遭入侵的证据。

3. 恶意软件包指标

审查特定软件包（新依赖项或被标记的软件包）是否遭到入侵时：

按严重程度从高到低检查：

• 滥用生命周期脚本 — preinstall/install/postinstall/prepare 钩子会获取并执行远程代码、解码 base64 数据块，或从环境变量中读取 CI/注册表凭据（NPM_TOKEN、GITHUB_TOKEN、云密钥）。
• 混淆 — 对于没有正当理由发布混淆源代码的软件包，其中包含经过压缩/打包的代码（大多数库并不需要这样做）。
• 网络数据外泄 — 在其他无关代码中嵌入了向原始 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 来源证明（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 显示存在已知易受攻击的版本	→ Skill 02（漏洞扫描器），用于 CVSS/EPSS/KEV 评分
已确认恶意软件包	→ Skill 05（恶意软件分析），对有效载荷进行静态/行为分析
怀疑生产环境中的流水线遭到入侵	→ Skill 07（事件响应）
流水线在云/K8s 环境中运行	→ Skill 10（云安全），用于审查 CI/CD 运行器和工作负载身份
需要进行合规映射（例如 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 来源证明