研究报告 · 约 25,126 字 · 预计推送 3 部分

软件供应链安全实践：SBOM、SLSA、Sigstore、依赖锁定与漏洞响应（综合报告） 未开始

目录

题记与说明

综合说明：本文由两份章节文件综合而成——纵轴章《……纵轴发展史（1999–2026）》（parts/2026-10-31-软件供应链安全-SBOM-SLSA-Sigstore-vertical.md）与横轴章《……横向对比》（parts/2026-10-31-软件供应链安全实践-SBOM-SLSA-Sigstore-依赖锁定-漏洞响应-horizontal.md）。综合时做了三件事：① 修正两章间的三处差异（EO 14306 的性质与范围、CycloneDX 当前版本、SLSA v1.2 精确日期），三项均已由综合会话于 2026-10-31 通过 WebSearch 二次核实；② 合并两章各自给出的个人项目安全基线，消除重复后收敛为三层（纵轴章的 Tier 0/1/2 与横轴章的 L0/L1/L2 两套自定命名统一为 Tier A/B/C，避免与 SLSA Build L0–L3 撞名），第三方 Action 的 pin SHA 由终稿修订会话经 git ls-remote 实查补齐；③ 全文统一时间线与术语。终稿另按独立审读意见修订：补齐 PEP 751 的纵轴条目、CISA 新版最低元素的日期与出处、NVD 收缩的原始报道链接、NuGet 现状限定、CRA 时钟对个人开源项目的适用性答案、npm 与容器镜像的消费端验证命令，并新增可直接粘贴的 security.yml / release.yml（附录 A）。凡标注"（转引）"的统计数字来自章节作者对原始报告的转引，未逐一回溯原始 PDF；全部核实与实查命令明细见文末"会话实查记录"，修订取舍见"诚实的边界"。

TL;DR

软件供应链安全是同一场攻防战的五条战线：SBOM 管"装了什么"（可观测），依赖锁定管"会不会被换"（完整性），SLSA 管"怎么造出来的"（出处），Sigstore 管"怎么证明"（签名+透明日志），漏洞响应管"多快知道、多快修"（时效）。27 年的历史规律只有一条：每个机制都是事故的后视镜——left-pad 之于 lockfile，SolarWinds 之于 SBOM/SLSA，Log4Shell 之于 VEX，XZ 之于"维护者信任"，Shai-Hulud 蠕虫之于默认 OIDC。站在 2026-10-31 的截面上：五个模块全部完成标准收敛（SPDX 3.0/ CycloneDX 1.7、SLSA v1.2、Cosign v3、PEP 751、OSV），竞争焦点从"要不要做"下移到"用哪套做"；防线从"开发者自觉"上移到"注册机构强制 + 监管强制"——npm 吊销 classic token、EU CRA 报告时钟生效，而美国联邦却在 EO 14306 中撤回 SBOM 采购要求。对个人开发者，结论是：不需要做任何标准选型，平台原生打底 + 开源工具补缺，两小时即可搭起一条完整的 provenance 签名发布链——这条链的组成环节（npm provenance、PyPI Trusted Publishers）2023 年当年就已免费可用，当年缺的只是 GitHub 构建物的官方出处签名（GitHub Artifact Attestations 2024-06 才 GA，见阶段四）；企业落地同类链路已不再难在选型，而是难在密钥托管、合规审计与多团队推广，往往需要专门团队与预算。

纵轴：发展脉络（1999–2026）

0. 一条主线，五条战线

这个课题表面上是五个名词的堆叠，实际上是同一场攻防战的五条战线。它们不是被"设计"出来的，而是被一波波事故"逼"出来的。整部历史可以概括为一条因果链：

事故（event-stream → SolarWinds → Log4Shell → XZ → Shai-Hulud）→ 政策（EO 14028 → EU CRA）→ 标准（SPDX/CycloneDX、SLSA、Sigstore、VEX）→ 生态默认值翻转（lockfile、OIDC trusted publishing、attestation）→ 响应基础设施重构（OSV、NVD 收缩、CVE 危机）

阶段一（1999–2015）：史前史——漏洞编号与依赖管理的"原始积累"

此阶段的特点：有了标准和数据库，但没有攻击者的压力——供应链安全还是合规部门的纸面话题。

阶段二（2016–2020）：社区自发工具期——从 left-pad 到 SolarWinds

阶段三（2021–2022）：政策引爆——EO 14028 与"SBOM 元年"

阶段四（2023）：provenance 落地之年——从"有规范"到"有默认值"

这一年的主题：普通开发者"发布一个包"的默认路径仍然不安全，于是各包生态做同一件事——把 provenance 和 OIDC 变成零成本的默认选项。

阶段五（2024）：现实检验——XZ 后门、NVD 失能与 SBOM 的"扩科"

阶段六（2025–2026）：默认安全收紧与"蠕虫时代"

六个阶段一张表

阶段SBOMSLSASigstore依赖锁定漏洞响应
1999–2015SPDX 1.0（2011）——Cargo.lock 随 Rust 1.0（2015）CVE（1999）/NVD（2005）
2016–2020CycloneDX 1.0（2017）—孵化（2019–2021-03）Yarn/npm lock/go.sumnpm audit、Dependabot
2021–2022NTIA 最低元素、ISO 5962v0.1（2021-05）LF 宣布 → GA（2022-10-25）hash 校验普及VEX、SSDF、M-22-18
2023进入采购合同v1.0（2023-04-19，移除源码要求）npm provenance GA（2023-09）PyPI Trusted PublishingOSV 生态、OpenVEX
2024CycloneDX 1.6 + ECMA-424、SPDX 3.0—GitHub Artifact Attestations GA（2024-06-25）PEP 740 定稿NVD 停摆、XZ 后门、CRA 生效
2025–2026CycloneDX 1.7（2025-10-21）、CISA 2026 版最低元素（2026-07-29 定稿）v1.1（2025-04）、v1.2（2025-11-24，Source Track）Cosign v3；蠕虫时代的底座PEP 751 接受（2025-03）；npm 吊销 classic tokens（2025-12-09）CVE 危机（2025-04）、EO 14306 撤回（2025-06）、NVD 只富化 KEV（2026-04）、CRA 报告义务（2026-09-11）

横轴：横向对比（2026-10-31 时间截面）

0. 截面速览与三层对比地图

在当前截面上，每个模块都完成了第一轮"标准收敛"，竞争从"要不要做"变成"用哪套做"：

模块本体与当前版本一句话定位近 18 个月关键变化
SBOMSPDX 3.0 vs CycloneDX 1.7 双雄并立"你的软件里有什么"双格式差距收窄，第三方建议双采
SLSAv1.2（2025-11-24），Build L0–L3 + Source Track"怎么被造出来的"Source Track 入正典；GitHub Attestations 成为"个人 SLSA Build L2 快捷通道"
SigstoreCosign v3（2025-10-08）+ Fulcio/Rekor"谁在什么身份下签的字"npm/PyPI 把 Sigstore 系凭证变成发布默认路径；Maven Central 起步
依赖锁定PEP 751 pylock.toml（2025-03 接受）；Dependabot vs Renovate"依赖版本由谁说了算"Python 终于有标准锁文件；npm 经典 token 全面失效
漏洞响应OSV-Scanner v2 + OpenVEX；商业 SCA 阵营"坏了多快知道、多快修"CRA 报告义务生效，响应从最佳实践变成合规义务

本课题是"实践组合"而非单一产品，横向对比分三层——每一层的"竞品"含义不同：标准层（谁的标准被采纳：SPDX vs CycloneDX、SLSA vs in-toto vs Scorecard、Sigstore vs Notary v2 vs GPG、OSV vs NVD vs GHSA、OpenVEX vs CSAF）；工具层（抢同一份 CI 预算：Syft/Trivy/cdxgen、OSV-Scanner/Grype vs Snyk/Mend/Black Duck/Endor Labs、Dependabot vs Renovate）；路线层（自建开源全家桶 vs 平台原生 vs 商业托管；注册机构强制 vs 自愿合规；欧盟强监管 vs 美国收缩）。

1. 标准层

SBOM：SPDX 3.0 vs CycloneDX 1.7 vs SWID。SPDX 出身许可合规、法律语义最强、ISO 国际标准身份；CycloneDX 安全起家、原生内置 VEX 与漏洞对象、安全工作流最顺；SWID 局限于设备管理场景。2026 年的共识是"差距收窄、双采为主"——CycloneDX 在 1.5→1.7 补齐许可与专利元数据，SPDX 的传统许可优势被压缩；第三方对比见 Interlynk（2026-06）、sbomify（2026-01）（转引）。OpenSSF 博客（2023）的公开口径是两大格式各自成熟、"黄金标准尚未定于一尊"（来源，转引），产出侧的通行建议因此是双格式同时交付。对个人项目：不用纠结——Syft/Trivy 同时输出两种格式，成本差为零。

构建完整性：SLSA v1.2 vs in-toto vs Scorecard。三者不是竞品而是堆叠：in-toto 是签名化 attestation 的数据底座，SLSA 是消费该格式的分级框架（Build Track 讲"构建时没被篡改"：L0 无 provenance → L1 有 provenance → L2 托管构建平台 → L3 加固构建，见 levels 页），Scorecard 是"横切自查"的 20 项检查器。v1.2 把源码侧（评审、分支保护、归属）正式带回正典——xz 式攻击恰好打在 Source Track 与 Build Track 的接缝上。其上的 VSA（Verification Summary Attestation）构成"证明的证明"，消费方不必重放整条验证链。对个人项目，Scorecard 的投入产出比远高于冲 SLSA 等级。

签名与证明：Sigstore/Cosign v3 vs Notary v2 vs GPG。实质是信任锚之争：Cosign 的信任锚是"OIDC 身份 + Rekor 公开透明日志"（私钥管理成本 ≈0），Notation 的信任锚是"企业 CA"（可接 KMS/HSM），GPG 是长期个人密钥（整体退潮）。2026 年选型共识：默认 Cosign，有既有 PKI/合规硬件要求选 Notation，云厂商绑定常替你做决定（来源：secure-pipelines.com、encryptionconsulting.com，转引）。注册机构是真正的分水岭：npm provenance GA 后 3800+ 项目带出处发布（转引）；PyPI 走 PEP 740；Maven Central 直到 2025-01-28 才允许验证 Sigstore 签名且 PGP 仍是必需（来源：central.sonatype.org）——Java 生态在签名现代化上落后 JS/Python 约两年。Rekor 累计签名量约 1.4 亿条量级（OpenSSF 2024 年报与检查点 API 口径，均为转引）。

漏洞情报与豁免声明：OSV vs NVD vs GHSA；OpenVEX vs CSAF。OSV 的胜出点是把漏洞当"版本区间查询"而不是"CVE 文档"，与锁文件天然对齐；NVD 在 2024 年断供风波后让出生态中心位；GHSA 只覆盖 GitHub 视角。VEX 侧，2026 年 CRA 排毒工作流的事实标准是 OpenVEX + 可达性分析：用 OpenVEX 文档豁免误报，配合调用链分析把"有洞"降级为"够不着"（来源：cra-decoded.com、OSV-Scanner changelog，转引）。

2. 工具层

SBOM 生成器：共识排序 Syft ≳ cdxgen > Trivy > MS SBOM Tool（TheCTOClub 2026 榜单、faun.dev 评分，第三方/转引，Anchore 系来源居多需打折）。真正的分野在"构建时 SBOM vs 源码/镜像扫描 SBOM"：源码推导对 Python/Go 可能不准（cdxgen#2223，转引），发布级 SBOM 应尽量在 CI 构建产物上生成——这一条直接决定了下文基线里 SBOM 放在 release 流程。

漏洞扫描与响应：开源三件套——Syft 生成 SBOM、Grype 消费 Syft 的 SBOM 做漏洞匹配、OSV-Scanner v2 补齐容器分层感知与修复引导（v2.2.x 加 Java 可达性）——对个人项目"够用且免费"；商业 SCA 的差异化只剩两点——企业许可合规（Black Duck/Sonatype）与降噪即优先级（Endor Labs 的可达性路线，厂商自述）。纯检测能力上商业与开源差距持续收窄（JetBrains Qodana 综述 + 多份对比稿交集，转引）。平台内置的 Dependabot 免费零配置，弱项是无可达性分析与策略豁免。

依赖更新：Dependabot vs Renovate——GitHub 上求省心用 Dependabot（10 行 YAML 够用），要控制力/monorepo/跨平台用 Renovate（来源：konvu.com、Renovate 官方对比页，转引）。

汇聚与策略层：Dependency-Track（SBOM 入库 + 风险面板）与 GUAC（把 SBOM、SLSA 证明、Scorecard、漏洞数据汇成可查询图，docs.guac.sh）是互补而非竞品。对个人项目两者都过重——SBOM 挂 Release + 本地 osv-scanner 即可。

3. 路线层：2026 年横轴上最大的三道分野

① 注册机构成为第一道防线（最重要的格局变化）。Shai-Hulud 两波蠕虫把"平台侧强制"从讨论变成既成事实：npm 撤销经典 token、granular token 限 90 天、Trusted Publishing 成为推荐路径、引入 staged publishing（docs.npmjs.com，转引）。Sonatype 2025 年报称全年新增恶意包 454,600+（厂商自报，转引）。个人项目供应链安全的一半，已经从"你自己做什么"变成"你发布到哪个平台、平台强制了什么"——npm/PyPI 是高水位，Maven Central（PGP 仍必需，见上文）次之；NuGet 居中：OIDC Trusted Publishing 已于 2025-09 前后上线并转正为推荐路径（Microsoft Learn，已核实），但其落后集中在现代化链路的后半段——Sigstore 系 provenance/attestation 缺位、作者签名可选，不及 npm/PyPI 的"发布即带出处"。

② 监管分野：欧盟上强度、美国踩刹车。欧盟 CRA 报告义务 2026-09-11 生效（24h/72h/14d 三段时钟，约束制造商；纯非商业个人开源不适用，见"常见追问"）、2027-12-11 全面适用；美国 EO 14306（2025-06-06）剥离了 EO 14028 系的 SBOM 采购与自证条款，2026 年初 OMB 撤销承包商自证（CRS IN12570、DWT，转引；CISA 的 SBOM 最低要素作为自愿事实标准存活）。同一年里，"SBOM 是否强制"在大西洋两岸给出了相反答案。

③ 工具路线：开源自建（零许可费、自己运维）vs 平台原生（GitHub 全家桶，≈0 成本覆盖 SLSA Build L0–L2 大部分场景） vs 商业托管（降噪/合规报表/团队规模红利）。个人项目的最优解几乎是注定的：平台原生打底 + 开源工具补缺口（SBOM 生成、容器签名）。

交叉洞察：两轴结合说明了什么

洞察一：机制是事故的后视镜，而"可验证性"决定采纳速度

纵轴给出的最强规律：left-pad 之于 lockfile，SolarWinds 之于 SBOM/SLSA，Log4Shell 之于 VEX，XZ 之于"维护者信任"，Shai-Hulud 之于默认 OIDC——判断一个实践会不会存活，看它回应的是哪场事故。在此基础上叠加横轴的观察：SPDX 诞生十年没出圈（阶段一），SLSA v1.0 把"等级"改成"可机器验证的 provenance"后三年内被三大包生态内置（阶段四）——"能被机器验证"是分水岭，可验证性决定采纳速度。两轴结合的推论：2026 年新冒出来的任何供应链安全提案，先问两个问题——它回应哪场事故？它能被 CI 里的机器验证吗？

洞察二：防线在持续上移，个人安全的一半已经"外包"出去

把纵轴的六个阶段排成一条线，防线的位置不断上移：仓库内自觉（lockfile、audit，2016–2020）→ 平台供给（Dependabot、Artifact Attestations，2019–2024）→ 注册机构强制（trusted publishing、token 吊销，2023–2025-12）→ 监管强制（CRA 三段时钟，2026-09 起）。横轴印证这是 2025–2026 的最大格局变化：npm/PyPI 的强制水位已经替开发者挡掉了"长期凭证"这一整类风险（2025-12-09 吊销 classic tokens），GitHub 的免费 Attestations 替开发者做掉了 SLSA Build L2 的 provenance。识别这类"外部已解决的问题"，是裁剪个人基线的方法论——外部已兜底的部分不要重复建设，个人精力只投在外部不管的部分（消费端验证、SBOM 交付、秘钥卫生）。

洞察三：政策弧线在 2025 年分岔——美国四年走完"强制→撤销"，欧盟接棒

纵轴的阶段三把 EO 14028 → M-22-18 讲成"采购权写进合同"的胜利，但横轴揭示了这条弧线的断点：2025-06-06 的 EO 14306 修订 EO 14144，剥离了 SBOM 采购与自证条款（已核实）。合并后的完整弧线是：EO 14028（2021-05）→ NTIA 最低元素（2021-07）→ M-22-18（2022-09）→ M-23-16（2023-06）→ EO 14306 撤回（2025-06）→ OMB 撤销自证（2026 年初）——从强制到撤回只用了四年。与此同时欧盟 CRA 用同样四个动作走完了立法流程并在 2026-09-11 启动报告时钟。对用户判断的含义：SBOM/VEX 的驱动力已从"美国政府采购"转移到"欧盟法域 + 下游企业客户的安全问卷"；单押任何一个法域的合规都是脆弱策略，正确姿势是把 SBOM/VEX 当作回归"工程质量实践"的东西来做——合规是副产品，不是目标。

洞察四：单一权威源是单点故障，多源化是唯一解

纵轴连续三年的坏消息构成一个完整的论证：NVD 富化停摆（2024-02，积压 1.8 万+）→ CVE 资金危机（2025-04，编号发放险些中断）→ NVD 只富化 KEV（2026-04，放弃全量分析承诺）。横轴则展示了市场的响应：OSV 把漏洞变成"包名@版本"的区间查询并成为事实接口，GHSA、CISA KEV、商业情报各自补位。两轴合起来的选型纪律只有一条：任何漏洞响应流程不得只依赖单一数据库——个人基线里 Dependabot（GHSA 系）+ osv-scanner（OSV 系）+ 每周定时重扫的组合，本质上就是这个原则的最小实现。

洞察五：攻击面的最终答案在"人与身份"，SLSA v1.2 是事故对标准的直接塑形

event-stream（2018，收养维护权）→ XZ（2024，两年社工渗透）→ Shai-Hulud（2025，蠕虫窃凭证自我复制）→ 2026 蠕虫反扑（连安全工具本身都被打）——纵轴显示攻击者早就完成了从"打代码漏洞"到"打人与凭证"的迁移；ReversingLabs 2026 年报的 +73% 恶意包、约 90% 集中在 npm（转引）说明这已进入指数传播模式。横轴展示的防御映射是一一对应的：OIDC 短时凭证消灭长期 token（npm 2025-12-09 强制）、attestation 消灭匿名发布（PEP 740、npm provenance、GitHub Attestations）、SLSA v1.2 Source Track 把评审与归属纳入分级（对 XZ 的直接回应）。特别注意 Source Track 的时点：v1.0（2023-04）曾把源码要求整体移出，社区担心"Source Track 难产"，结果 2025-11 的 v1.2 把它正式带回——XZ 后门发生在 v1.0 发布一年之后，标准的"补课"就是被这场事故逼出来的。这是"机制是事故的后视镜"规律在标准演进层面最干净的一次复现。

洞察六：对个人开发者的判断与建议（合并两章基线后的统一版）

核心判断：2026 年，个人项目与企业的基线差距已缩小到"两小时"——GitHub Artifact Attestations（2024-06 GA）+ Trusted Publishing + Dependabot + osv-scanner，两小时内能搭起一条完整的 provenance 签名发布链。需要把话说准：这条链的组成环节（npm provenance、PyPI Trusted Publishers）2023 年当年就已免费可用，2023 年缺的只是 GitHub 构建物的官方出处签名（Artifact Attestations 2024-06 才 GA，见阶段四）；"两小时"指的是个人开发者的配置时间，企业要落地同等链路，差距不在能力或选型，而在密钥托管、合规审计与多团队推广，往往需要专门团队与预算。不需要做任何标准选型，照抄默认值即可。

统一最小基线（三层；第三方 Action 的版本 tag 出自横轴章会话的 gh api 实查，commit SHA 出自本终稿会话的 git ls-remote 实查，均为 2026-10-31，明细见文末实查记录）：

威胁 ↔ 动作对照表（证明"最小"不是随意裁剪）：

攻击向量真实案例对应动作
维护者 token 被盗→蠕虫传播Shai-Hulud 两波（2025-09/11）Trusted Publishing（无长期 token）+ 90 天 granular token
安装脚本投毒Shai-Hulud 的 preinstallnpm ci --ignore-scripts（代价：esbuild/sharp/node-gyp 系原生包会被跳过装坏；对策见"常见追问"五）；不裸跑 npx <未固定包>
构建时篡改XZ Utils（2024-03）CI 构建而非本地发包 + attest-build-provenance
依赖混淆/typosquattingtorchtriton（2022-12）；常态恶意包 45 万+/年（转引）lockfile 冻结 + 消费端 verify
历史泄漏的密钥s1ngularity（2025-08）Secret scanning + push protection + gitleaks 全历史
CI Action 被投毒GitHub Actions tag 复用攻击Action pin 到完整 commit SHA（tag 仅作注释）+ actions 纳入 Dependabot
用了含洞版本而不自知Log4Shell 的教训osv-scanner 定时重扫 + Dependabot alerts

明确不建议个人项目做的：自建 Sigstore/Fulcio/Rekor（公共好实例已免费覆盖）；追 SLSA Build L3（hermetic 构建性价比极低，L2 够用）；手写 VEX 或维护正式 SBOM 分发渠道（VEX 等有下游真实消费者再说）；自建私有 registry（那是企业内网问题）；部署 Dependency-Track/GUAC 这类常驻服务（过重）。

常见追问

追问一：完整可粘贴的 security.yml / release.yml 在哪？
附录 A。其中所有第三方 Action 均 pin 到 2026-10-31 经 git ls-remote 实查的 commit SHA（tag 写在行尾注释），升级时先更新注释里的 tag、再取新 SHA 替换。再次强调"诚实的边界"：相关会话均未实际运行过这些工作流（无对应仓库与 runner），使用前请以各官方 release 页为准。

追问二：npm 包与容器镜像的消费端验证命令？

追问三：CRA 的 24h/72h/14d 时钟适用个人开源项目吗？
分三种身份：① 纯非商业 FOSS（免费分发、不收费、无付费支持/商业化捆绑）不构成 CRA 意义上"投放市场"的产品，制造商义务（含第 14 条报告时钟）不适用；② 以"开源软件管理员"（open-source software steward，第 24 条）身份持续维护项目的组织/个人只承担轻义务——安全策略、配合漏洞信息共享——不背制造商时钟；③ 一旦收费、卖付费支持/订阅、把项目捆绑进商业分发，就可能被认定为制造商，时钟适用（2026-09-11 起）。一句话："周末发包不触发时钟，靠项目收钱要查表"。条款口径综合自第三方合规指南（转引；FOSS 豁免落在序言的条号在不同指南间有出入，故本文不引具体序言号），正式文本以 EUR-Lex 为准。

追问四：PEP 751 的 pylock.toml 与基线推荐的 uv.lock 什么关系、提交哪个？
uv.lock 是 uv 的原生锁文件，保留 uv 全部能力（多平台统一解析、可编辑安装、uv 特有依赖特性）；pylock.toml 是 PEP 751 定下的跨工具标准格式（2025-03 接受）。uv 支持 uv export --format pylock.toml 从 uv.lock 导出标准格式，也能直接从 pylock.toml 同步环境——但 uv 作者明确表示它尚不足以完全替代 uv.lock（缺 uv 特有特性）。建议：仓库提交 uv.lock 作单一事实源；下游或审计方需要标准格式时，在 CI 里导出 pylock.toml 随发布物交付；不要把两份锁文件同时当事实源双维护。

追问五：npm ci --ignore-scripts 会不会把东西装坏？
会——它跳过所有 install 脚本，esbuild、sharp、node-gyp 系等依赖 postinstall 下载/编译原生产物的包会装上不可用。这是"默认拒绝、按需放行"的取舍，不是免维护开关：① 对确需脚本的可信包，以 --ignore-scripts=false 单独安装或重建放行；② 或整体换 pnpm，用 onlyBuiltDependencies 白名单精确放行（名单外的脚本一律不跑）；③ 该开关在 CI 与新依赖首次引入时保持开启，本地日常安装自行权衡。威胁表里它对应 Shai-Hulud 式 preinstall 投毒——宁可装坏可诊断，不可装进后门。

诚实的边界

附录 A：可直接粘贴的 `security.yml` 与 `release.yml`

模板状态：未实际运行（无对应仓库与 runner）。所有 Action 的 SHA 均为 2026-10-31 经 git ls-remote <repo> refs/tags/<tag> 实查所得（轻量 tag 即 commit 本身，附注 tag 已做脱引用 ^{} 核对），tag 对照表见 YAML 注释与文末实查记录。官方 Action（actions/*）同样按 SHA pin——它们一样可能被 tag 复用攻击。

.github/workflows/security.yml（Tier B：密钥泄漏全历史扫描 + 依赖漏洞每周重扫，结果进 Security 面板）：

name: security

on:
  push:
    branches: [main]
  pull_request:
  schedule:
    - cron: "17 3 * * 1" # 每周一 UTC 03:17 定时重扫：新 CVE 是补发出来的
  workflow_dispatch:

permissions: {} # 顶层零权限，逐 job 下放

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write # PR 内评论告警用
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0 # 全历史扫描
      - uses: gitleaks/gitleaks-action@e0c47f4f8be36e29cdc102c57e68cb5cbf0e8d1e # v3.0.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # GITLEAKS_LICENSE: 仅组织账号需要（gitleaks.io 免费申请），个人账号无需

  osv-scan:
    # 官方 reusable workflow：内部完成扫描、SARIF 生成与 Code Scanning 上传
    # 注意：scan-args 不能设 --format/--output，由该 workflow 自行控制
    uses: google/osv-scanner-action/.github/workflows/osv-scanner-reusable.yml@b1d267aea5211fa648d9d442fa64b90dbdcbdd36 # v2.7.0
    permissions:
      contents: read
      security-events: write
      actions: read
    with:
      scan-args: |-
        -r
        ./

.github/workflows/release.yml（Tier C：三个独立 job，按需删减——① GitHub 构建物出处签名 + SBOM 随 release 上传，② PyPI Trusted Publishing，③ npm Trusted Publishing）：

name: release

on:
  release:
    types: [published]

permissions: {}

jobs:
  # ① 构建产物 + 出处签名（SLSA Build L2 级）+ SBOM 随 release 上传
  build-attest:
    runs-on: ubuntu-latest
    permissions:
      contents: write      # 上传 release 资产
      id-token: write      # Sigstore keyless / attestation
      attestations: write  # GitHub Artifact Attestations
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: astral-sh/setup-uv@68559e99cc807c1eb7e9238fd43a15bba460eec2 # v10.3.3
      - run: uv build
      - uses: actions/attest-build-provenance@4d101475d8b20a2381f78447822ac1eab6504dd8 # v4.2.2
        with:
          subject-path: "dist/*"
      - uses: anchore/sbom-action@66cbf4bc1f1c0d2edc94016e65bc221b6bb0ad6c # v0.24.3
        with:
          format: cyclonedx-json
          upload-release-assets: "true" # 默认即 true，写出来是提醒你它在传什么

  # ② PyPI：Trusted Publishing（先在 PyPI 侧把 <owner>/<repo> + environment 名登记为 Trusted Publisher）
  publish-pypi:
    needs: build-attest
    runs-on: ubuntu-latest
    environment: pypi
    permissions:
      contents: read
      id-token: write # OIDC 短时凭证，取代长期 API token
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: astral-sh/setup-uv@68559e99cc807c1eb7e9238fd43a15bba460eec2 # v10.3.3
      - run: uv build
      - uses: pypa/gh-action-pypi-publish@7245906fb61fa33a13554f9d5fb856fe61758086 # v1.14.3
        # 默认上传 dist/，自动生成 PEP 740 attestation

  # ③ npm：Trusted Publishing（先在 npm 侧把 <owner>/<repo> + environment 名登记为 Trusted Publishing）
  publish-npm:
    needs: build-attest
    runs-on: ubuntu-latest
    environment: npm
    permissions:
      contents: read
      id-token: write # provenance 签名需要
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
        with:
          cache: npm
      - run: npm ci --ignore-scripts # 代价与对策见"常见追问"五
      - run: npm publish --provenance

使用说明三行：

  1. 只发布 Python 的删掉 publish-npm，只发 npm 的删掉 publish-pypi，纯应用仓库删掉两个 publish job 只留 build-attest；
  2. environment: pypi/npm 必须与两个注册机构后台登记的 GitHub environment 名一致，这是 Trusted Publishing 的对账凭据；
  3. 消费端验证命令见"常见追问"二。

参考来源

标准与规范

Sigstore 与签名

平台与注册机构

漏洞响应

工具对比（第三方/转引居多）

监管

事件

两份章节文件的会话实查记录（引自横轴章，供复核）：gh api repos/{actions/attest-build-provenance,anchore/sbom-action,google/osv-scanner-action,astral-sh/setup-uv,pypa/gh-action-pypi-publish,gitleaks/gitleaks-action}/releases/latest；gh attestation --help（gh 2.94.0）；uv export --help（uv 0.10.8）；npm publish --help（npm 11.19.1）；command -v osv-scanner gitleaks syft grype trivy cosign（均未安装）。

综合会话新增核实（2026-10-31，WebSearch）：EO 14306 性质与范围（DWT/Wiley/Federal Register 口径）；CycloneDX 1.7 发布日期（cyclonedx.org/specification/overview）；SLSA v1.2 发布日期与 Source Track（slsa.dev/blog）。

终稿修订会话新增实查与核实（2026-10-31）：

  1. git ls-remote <repo> refs/tags/<tag> 实查 Action 的 commit SHA（轻量 tag 即 commit，带 ^{} 脱引用核对）：gitleaks/gitleaks-action v3.0.0 → e0c47f4f8be36e29cdc102c57e68cb5cbf0e8d1e；google/osv-scanner-action v2.7.0 → b1d267aea5211fa648d9d442fa64b90dbdcbdd36；pypa/gh-action-pypi-publish v1.14.3 → 7245906fb61fa33a13554f9d5fb856fe61758086；astral-sh/setup-uv v10.3.3 → 68559e99cc807c1eb7e9238fd43a15bba460eec2；actions/attest-build-provenance v4.2.2 → 4d101475d8b20a2381f78447822ac1eab6504dd8；anchore/sbom-action v0.24.3 → 66cbf4bc1f1c0d2edc94016e65bc221b6bb0ad6c；actions/checkout v7.0.1 → 3d3c42e5aac5ba805825da76410c181273ba90b1；actions/setup-node v5.0.0 → a0853c24544627f65ddf259abe73b1d18a591444。SHA 以实查当日远端为准，升级时请重新实查。
  2. 读取 pinned commit 处的源文件核对用法：gitleaks-action README（v3 用法、GITHUB_TOKEN、组织需 license、fetch-depth: 0 全历史）、osv-scanner-reusable.yml（scan-args 不得含 --format/--output、默认 -r ./、内部自传 SARIF、checkout 固定 v7.0.1）、anchore/sbom-action 的 action.yml（format 默认 spdx-json、artifact-name、upload-release-assets 默认 true）、actions/attest-build-provenance 的 action.yml（subject-path 支持通配、show-summary 默认 true）。
  3. WebSearch/WebFetch 核实：CISA 2025 版 SBOM 最低元素草案发布于 2025-08-22（征求意见至 2025-10-03）、2026 版定稿 2026-07-29（CISA 资源页）；NVD 2026-04-15 收缩（NIST 公告 + Recorded Future 2026-05-14 起的追踪文，富化覆盖面约 15–20%）；NuGet.org Trusted Publishing 于 2025-09 前后上线并转正（Microsoft Learn、Andrew Lock），作者签名可选、无 Sigstore 系 provenance；CRA 第 14 条报告时钟与第 24 条 steward 义务、FOSS 非商业供给豁免（eu-cyber-laws.com 等第三方指南；序言条号在不同指南间有出入，正文未引具体序言号，正式文本以 EUR-Lex 为准）；npm audit signatures（npm 9+，校验已装依赖签名与 provenance）；gh attestation verify oci://…（GitHub Docs 与 CLI 手册）；uv export --format pylock.toml（uv 文档）。
  4. 删除无法溯源的表述：原稿"OpenSSF 建议两个都强制采纳"（未找到 OpenSSF 原始条目）；原稿 CISA 草案"增加组件哈希、许可证、生成语境"的具体清单（CISA 资源页未列明，改为页面可证的"新增必填数据元素、定义覆盖度口径"）。

思考题（读完后想一想，参考答案可展开）

  1. 报告把软件供应链安全概括为“同一场攻防战的五条战线”，并提炼出一条贯穿 27 年的历史规律。请说明五条战线各自管什么，以及“机制是事故的后视镜”这一规律的具体对应关系。
    参考答案

    五条战线：SBOM 管装了什么，依赖锁定管会不会被换，SLSA 管怎么造出来的，Sigstore 管怎么证明，漏洞响应管多快知道多快修。规律是“每个机制都是事故的后视镜”：left-pad 之于 lockfile，SolarWinds 之于 SBOM/SLSA，Log4Shell 之于 VEX，XZ 之于“维护者信任”，Shai-Hulud 蠕虫之于默认 OIDC。

  2. 在 SBOM 标准层的横向对比中，SPDX 3.0 与 CycloneDX 1.7 各有什么侧重？2026 年的选型共识是什么？对个人项目又意味着什么？
    参考答案

    SPDX 出身许可合规、法律语义最强、是 ISO 国际标准；CycloneDX 安全起家、原生内置 VEX 与漏洞对象，安全工作流最顺。2026 年共识是“差距收窄、双采为主”：CycloneDX 在 1.5→1.7 补齐许可与专利元数据，SPDX 传统许可优势被压缩，通行建议是双格式同时交付。对个人项目不用纠结：Syft/Trivy 同时输出两种格式，成本差为零。

  3. XZ Utils 后门为什么被报告称为“本课题历史上最深刻的一课”？它暴露了 SBOM/SLSA/Sigstore 的什么盲区？SLSA v1.2 是如何直接回应这场事故的？
    参考答案

    2024-03-29 的 XZ Utils 后门中，攻击者“Jia Tan”用约两年取得维护权植入后门——报告称 SBOM/SLSA/Sigstore 全都防不住“维护者本人被收编”。直接回应是 SLSA v1.2（2025-11-24）新增完整 Source Track，把评审、归属、版本控制纳入分级，补上 v1.0 移除源码要求后缺的半边——标准的“补课”就是被这场事故逼出来的。

  4. 报告对个人开发者的核心判断是“两小时”差距与“平台原生打底 + 开源工具补缺”。这一判断背后的裁剪方法论是什么？又明确不建议个人项目做哪些事？
    参考答案

    核心判断：2026 年个人与企业的基线差距已缩到“两小时”，无需做标准选型。方法论是“识别外部已解决的问题”：npm 吊销 classic tokens、GitHub 免费 Attestations 已替开发者兜底，个人精力只投外部不管的部分——消费端验证、SBOM 交付、密钥卫生。明确不建议自建 Sigstore、追 SLSA Build L3、手写 VEX、自建私有 registry。

← 资料库今日播报 →