依赖与供应链安全：SBOM、扫描与签名验证

0. 元信息

• 主题路径：docs/topics/web-security/subtopics/web-security-supply-chain/
• 父主题：web-security
• 主分类：安全与可靠性
• 辅助分类：工程技术
• 适合对象：后端、平台、SRE、DevOps
• 建议周期：1～1.5 周（每周 6～8 小时）
• 前置知识：linux-dev-env / git-and-collaboration；会用 npm/pip/Cargo 与 Docker
• 最终目标：能为项目生成 SBOM（SPDX 或 CycloneDX），在 CI 中跑依赖与容器扫描，对接 CVE feed（NVD/GHSA/CISA KEV），并能用 sigstore/cosign 做镜像与工件签名验证

1. 学习路线

供应链攻击面（直接依赖 / 间接依赖 / 镜像 / 包注册表）
  → SBOM：SPDX、CycloneDX
  → 依赖扫描：npm audit、pip-audit、Cargo audit
  → 商业扫描：Snyk、Dependabot、Renoate、OSS Review Toolkit
  → 容器扫描：Trivy、Grype、Clair
  → 签名验证：sigstore / cosign / in-toto / SLSA
  → CVE feed：NVD / GHSA / OSV / CISA KEV
  → 自动化响应：高危 CVE 自动建 Issue
  → 减少攻击面：最小依赖、固定版本、镜像 slim

2. 阶段周数分配

建议周期 8 周，每周 6 天、每天 1.5～2 小时（每周约 9～12 小时），第 7 天用于复盘和补测：第 1 周基础模型与威胁边界；第 2～3 周核心机制；第 4～5 周防御实现；第 6 周检测、测试与审计；第 7 周综合演练；第 8 周项目收尾、复盘与最终验收。

3. 九阶段表

关键陷阱：传递依赖最大；SBOM 只列组件不查漏洞；签名验证不是 build 完整性；“修复版本存在”不等于”我们能升级”。

4. 第一周：基础与威胁建模（每天 1.5～2 小时）

5. 阶段通用验收

• 阶段 1 验收：完成概念地图；提交威胁模型；能用 10 分钟解释核心资产、信任边界和主要攻击面。
• 阶段 2 验收：完成核心机制最小实现；提交 3 组正向与负向测试；测试输出包含成功和拒绝结果。
• 阶段 3 验收：完成防御实现；提交配置/代码审计清单；所有高风险输入均经过验证、编码或安全 API。
• 阶段 4 验收：完成检测或安全测试规则；提交日志/扫描/测试输出；能从证据定位触发点和影响范围。
• 阶段 5 验收：完成一次事件或攻击链演练；提交时间线、处置动作和恢复验证；复现者按 README 可独立运行。
• 阶段 6 验收：完成综合项目核心功能；边界测试全通过；README、notes/design.md、notes/test.md、notes/retrospective.md 均存在且非空。
• 阶段 7～8 验收：修复复盘发现的问题；重新执行全部命令；最终报告记录版本、命令和结果。

6. 最终验收

学完后应能完成威胁建模、选择合适的安全机制、实现最小防御链路、编写负面测试、读取日志或扫描证据，并向团队解释安全权衡和残余风险。

量化标准：

• 完成至少 24 道相关练习，其中 12 道基础、8 道中等、4 道综合/高难；每题保留测试或答案证据。
• 独立写出至少 4 个可运行 demo，每个包含成功路径和至少 3 个拒绝/异常测试。
• 完成 1 次 60 分钟攻击—防御演练，能在 15 分钟内讲清威胁模型、核心流程和修复理由。
• 综合项目的自动化检查通过率 100%，高危问题数 0，README 可让他人在 10 分钟内复现。

7. 综合项目

首选项目：安全 Web 服务实验室（本主题对应的 “）。实现一个最小 HTTP/API 服务，故意保留一条可控弱点，再用安全实现和自动化测试修复它。

备选项目：安全审计 CLI。读取请求、配置或依赖清单，输出风险、证据、严重性和修复建议。

必做要求：

• 输入：明确的 JSON/HTTP 请求、配置文件或依赖清单；拒绝缺失字段、超长值、非法编码和越权对象。
• 输出：机器可读 JSON 报告或 API 响应，并包含状态、错误码、证据、修复建议；日志不得泄露密码、令牌或密钥。
• 算法/工具：按 §3 选择标准库安全 API、参数化查询、策略匹配、哈希/签名、规则扫描或事件时间线；在 README 说明选择理由与复杂度/局限。
• 验收标准：成功路径通过；至少 10 个边界/负面测试通过；高风险输入被拒绝；运行静态检查或扫描无新增高危；输出可复现。

项目根目录必须包含 README.md、notes/design.md、notes/test.md、notes/retrospective.md。README 需写需求说明、数据结构/工具选择理由、核心流程、模块化实现、边界测试、编译/运行说明、目录结构和复盘记录；notes/design.md 写威胁模型与流程图，notes/test.md 写每组输入/期望/实际输出，notes/retrospective.md 写用时、难点、收获和下一步。

本主题贡献

• 职责 1（SBOM 每构建生成 + 多层扫描）：每次 CI 构建跑 syft 或 cdxgen 生成 CycloneDX 1.6 SBOM，与 SPDX 二选一落工件（§3 阶段 2、§9.6.3）；随后跑 Trivy 多目标扫（filesystem + image + iac），osv-scanner 命中 OSV 数据库；高危 CVE 让构建失败，对应 §9.4 #4 / #8。
• 职责 2（cosign 签名 + SLSA 来源）：所有生产镜像与构建产物用 cosign sign --keyless（OIDC + Fulcio）或 KMS 签名；部署时 cosign verify --certificate-identity … --certificate-oidc-issuer …（§3 阶段 6、§9.3.5 “Sign + verify”）；CI 上传 SLSA provenance（Level ≥2），呼应 SolarWinds 教训（§9.4 #1）。
• 职责 3（CVE feed + 自动响应 + 减少攻击面）：订阅 NVD / GHSA / OSV / CISA KEV 四路，与 SBOM 比对；高危 CVE 24h 内开 Issue + Dependabot/Renovate 自动升级 PR（§3 阶段 7~8、§9.4 #5）；依赖最小化、固定版本 + lockfile 进 git、镜像 multi-stage + distroless / slim（§3 阶段 9）；cosign 私钥用 KMS，禁写 CI 配置（呼应 §10 误区）。
• 交付物 1：CI 工件 bom.cdx.json + bom.spdx.json 每次构建产出并保留 ≥90 天；trivy-report.sarif 上传 GitHub Security Tab；osv-scanner 结果落 security-audit/。
• 交付物 2：scripts/sign-and-verify.sh 演示 cosign sign-blob + cosign verify-blob；infra/k8s/deployment.yaml 含 imagePullSecrets 关联 cosign 公钥 + 验证策略（Kyverno / Connaisseur / Ratify 之一）。
• 交付物 3：scripts/cve-watch.ts 拉 NVD / GHSA / OSV / KEV，与仓库 SBOM 比对，命中 KEV 即建 Issue 标 priority/P0、自动派 owner；写入 cron。
• 交付物 4：docs/dependency-policy.md 写明“最小依赖、固定版本、lockfile 进 git、major 升级 staging 回归、Dependabot 按 severity 分批合并”；Dockerfile 演示 multi-stage + gcr.io/distroless/static。
• 指标 1：SBOM 覆盖率 100%——syft dir:. 输出组件数 ≥ package-lock.json + requirements.txt + Cargo.lock 合并去重数；镜像扫描覆盖率 100%（所有 docker push 必经 cosign + Trivy）。
• 指标 2：CISA KEV 命中本仓库组件的 CVE，24h 内自动建 Issue + 派单率 ≥95%；Trivy 高危（CRITICAL/HIGH）镜像 100% 拦截推送，CI 拒绝合并。
• 指标 3：cosign 签名 / 验证闭环——生产环境 100% 镜像在部署时 cosign verify 通过；任何未签名 / 验签失败的镜像在集群准入控制（Admission Webhook）层被拒绝。

8. 推荐开源资料

许可证提示：使用 OWASP、ZAP 或其他开源资料与源码前，先打开仓库或页面的 LICENSE/版权说明；默认只引用链接和思路，复制代码时保留版权与许可证文本。

默认使用顺序：先读 §1 与 OWASP 入门资料建立模型 → 用 MDN/规范查 API 和约束 → 在本地项目实现 → 用 ZAP 或对应扫描工具验证 → 到 PortSwigger 做练习 → 将证据和复盘写入 notes/。

9. 学习资料汇聚（v0.3 自包含）

9.1 背景与动机

OWASP Top 10 2021 把”A06 Vulnerable and Outdated Components”与”A08 Software and Data Integrity Failures”列为前几位。前者关心”我们用了什么”，后者关心”我们信不信它”。

历史上踩过的坑：

• 2017 event-stream：npm 包被植入恶意代码，影响数千项目；
• 2020 SolarWinds Orion：构建系统被入侵，恶意更新推送 18,000 客户；
• 2021 ua-parser-js / colors.js / coa：npm 包作者邮箱被盗，恶意版本发布；
• 2021 Log4Shell：几乎所有 Java 应用都受影响；
• 2022 Spring4Shell：Spring 框架 RCE；
• 2023 3CX Desktop App：供应链渗透到最终产品。

它们共同指向一件事：第三方代码 = 攻击面。修复不能等到漏洞发现，要从引入那一刻就治理。

9.2 概念地图

flowchart LR
  Supply[供应链安全] --> SBOM
  Supply --> Audit[依赖扫描]
  Supply --> Sign[签名验证]
  Supply --> CVE[CVE feed]
  SBOM --> SPDX
  SBOM --> CycloneDX
  Audit --> NpmAudit[npm audit]
  Audit --> PipAudit[pip-audit]
  Audit --> CargoAudit[cargo audit]
  Audit --> Trivy[Trivy / Grype]
  Audit --> Snyk[Snyk]
  Audit --> Dependabot[Dependabot / Renovate]
  Sign --> Sigstore[sigstore / cosign]
  Sign --> SLSA[SLSA 框架]
  Sign --> InToto[in-toto]
  CVE --> NVD
  CVE --> GHSA[GitHub Security Advisory]
  CVE --> OSV[OSV.dev]
  CVE --> KEV[CISA KEV]
  Att[攻击面] --> Direct[直接依赖]
  Att --> Transitive[传递依赖]
  Att --> Image[容器镜像]
  Att --> Build[构建系统]
  Response[响应流程] --> SLA[高危 CVE 24h]
  Response --> AutoPR[自动升级 PR]
  Response --> Pin[版本固定]
  Reduce[减少攻击面] --> MinDeps[最小依赖]
  Reduce --> Slim[slim 镜像]
  Reduce --> Verify[锁定文件进 git]

关系说明：SBOM 是底座；依赖扫描与 CVE feed 命中 SBOM；签名验证负责”信不信”；自动化响应让 SLA 可达；减少攻击面降低风险基数。

9.3 基础知识讲解

9.3.1 经典论文 / 标准

主推：OWASP A06/A08 + CycloneDX + SLSA。备查：NIST SSDF、in-toto、OWASP CI/CD Top 10。

9.3.2 经典书籍

主推：Cassidy《Software Supply Chain Security》。备查：Liz Rice《Container Security》。

9.3.3 优秀博客 / 文档

主推：Snyk + OSV + CISA KEV + Trivy。备查：npm audit / pip-audit、CycloneDX tooling、SLSA、sigstore。

9.3.4 核心人物

主推：Dan Lorenc、Kim Lewandowski。备查：Moshe Zadka、Tony Arcieri。

9.3.5 开发方法

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• SBOM：组件清单；不含漏洞；
• 依赖扫描：把 SBOM 与 CVE 库匹配；
• 容器扫描：扫描镜像内文件系统；
• 签名验证：验证工件未被篡改；不替代 SBOM；
• CVE feed：公开漏洞；不含利用情况；
• CISA KEV：已知被利用漏洞；优先级更高；
• VEX：供应商漏洞说明；解释”我们不受影响”。

9.6.3 Structure

必会字段、接口、API：

• SBOM 字段：bom-ref、name、version、purl（Package URL）、licenses、hash；
• 依赖文件：package.json + package-lock.json、requirements.txt + pip-resolved、Cargo.toml + Cargo.lock、go.mod + go.sum；
• 签名：cosign sign、verify；
• SLSA Level 1~3：构建来源、构建服务、构建完整性；
• CVE feed：JSON / Atom；webhook 订阅；
• CI 集成：GitHub Actions / GitLab CI / Jenkins + 扫描器。

9.6.4 Ecosystem

• SBOM 生成：cyclonedx-bom、cyclonedx-python-lib、spdx-tools、syft、cdxgen；
• 依赖扫描：npm audit、pip-audit、cargo audit、bundler-audit、composer audit、OWASP Dependency Check；
• 商业扫描：Snyk、GitHub Dependabot、GitHub Code Scanning、GitLab Secure、Renovate；
• 容器扫描：Trivy、Grype、Clair、Anchore、Docker Scout；
• 签名：cosign（sigstore）、in-toto、Notary v2；
• CVE 数据库：NVD、GHSA、OSV、CISA KEV、Snyk Vulnerability DB；
• 事实标准 vs 标准本身：npm 默认行为（audit 仍需要显式运行）、Docker 默认 scan 行为（部分云厂商默认开）；这些不是 RFC 但部署要知道。

9.6.5 Depth Tiers

本计划目标：L3。

9.6.6 Source

• OWASP 仓库：https://github.com/OWASP/
• NIST 仓库：https://csrc.nist.gov/
• CycloneDX：https://cyclonedx.org/
• SPDX：https://spdx.dev/
• SLSA：https://slsa.dev/
• sigstore / cosign：https://docs.sigstore.dev/
• CISA KEV：https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• OSV：https://osv.dev/
• 引用版本快照日期：2026-07-30。

10. 常见误区

• 有了 SBOM 就以为安全了；
• 锁定文件未进 git；
• 直接升级 major 版本（破坏性变更无回归测试）；
• 用 npm audit fix 不看 diff；
• 容器基础镜像不更新；
• 镜像签名只签生产环境，staging 不签；
• cosign 私钥写在 CI 配置里；
• 升级到”修复版本”但兼容性未测；
• 没订阅 CVE feed，靠人肉看新闻；
• “包作者可信”，无所有权变化监控；
• 镜像 slim 化但运行时库未验证；
• 跑 pip-audit 但忽略传递依赖；
• 镜像扫描只扫 base image，不扫应用层；
• SBOM 存放但没和 CVE feed 关联；
• 自动升级 PR 太多，没人审；
• 用 Snyk 商业扫描但不接 KEV；
• in-toto layout 写完没验证；
• 不写”不可用”的理由（VEX）。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础
4. 工程技术
5. Web 与后端
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力
9. 安全与可靠性

本计划归属：安全与可靠性 主 + 工程技术 辅。