国外软件供应链安全进展：法规、基金会与大厂实践

当 SolarWinds 在 2020 年底把"软件供应链"这五个字推到白宫战情室桌上时，没有人预料到，五年之内它会变成一份贯穿大西洋两岸的法规、基金会项目与企业内审计清单。本文梳理 2021–2026 年美国、欧盟、英国三大法域的政策时间表，并把 OpenSSF、Linux Foundation、CNCF 的项目矩阵与 Google、Microsoft、AWS、GitHub 的内部实践放在一张图里观察。我们尤其关注两个被 SCA 厂商市场宣传容易混淆的维度：时间表——什么时候开始执行；以及约束力——它是建议、自证还是法律强制。下一篇（07）转入中国视角，本篇先把"国外这盘棋"摆开。

一、美国：从 EO 14028 到 2025 SBOM Minimum Elements 的五年闭环

美国是全球软件供应链监管节奏最密、文件最多的法域。从 2021 年的总统行政令到 2025 年的 SBOM 字段升级，五年内形成了"行政令——NIST 框架——OMB 命令——CISA 工具"的四段式闭环，每一段都对应一类约束力。

1.1 EO 14028（2021-05-12）：把"软件供应链"写进总统行政令

2021 年 5 月 12 日，拜登签署 Executive Order 14028: Improving the Nation's Cybersecurity。这是 SolarWinds 事件后的第一份白宫级回应文件，全文约 8000 字，其中 Section 4「Enhancing Software Supply Chain Security」单节占据近三分之一篇幅，是全篇分量最重的章节¹。

Section 4 的核心要求按时间表排开：

• 90 天内：NIST 联合 NSA、OMB、CISA、DNI 给"关键软件（critical software）"下定义；
• 180 天内：NIST 发布 SSDF 草案；
• 360 天内：NIST 完成完整供应链安全指南。

具体条款中影响最深远的是 4(e) 和 4(g)–4(s)：4(e) 要求联邦机构采购软件时由供应商提供"安全开发证明（attestation）"并强制使用 SBOM；4(g)–4(s) 涵盖消费者 IoT 标签、关键软件清单、漏洞披露策略等。EO 14028 的真正历史意义在于，它把"软件供应链安全"从行业自律强行推到了联邦法律强制层——任何要把软件卖给联邦政府的供应商都必须对齐 NIST SSDF 与 SBOM 要求，否则进不了 GSA 采购目录。

1.2 NIST SP 800-218 SSDF v1.1（2022-02）：四类实践、19 项任务

为执行 EO 14028 的 4(c)/4(d) 条款，NIST 于 2022 年 2 月发布 Secure Software Development Framework v1.1²。框架由四类实践构成：

• PO（Prepare the Organization）——组织级准备：工具链、人员培训、安全角色；
• PS（Protect the Software）——保护软件：代码完整性、签名、机密管理、归档；
• PW（Produce Well-Secured Software）——安全开发：威胁建模、SAST/DAST、依赖审查；
• RV（Respond to Vulnerabilities）——漏洞响应：CVD、补丁、根因分析。

合计 19 项实践、42 项任务。SSDF 本身没有强制约束力（NIST 特别出版物属于"建议"性质），但下文 OMB M-22-18 通过自证条款把它"强制化"了——这是美国监管路径的典型套路：NIST 写技术、OMB 加约束。

NIST 已发布 SP 800-218 Rev.1（v1.2）公开草案，更名为"网络安全 SSDF"，扩展了 AI/ML 与生成式 AI 场景，原计划独立发布的 SP 800-218A（GenAI Profile）被并入 v1.2³。

1.3 NIST SP 800-204D（2024-02）：SSDF 落地到 CI/CD

2024 年 2 月发布的 Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines 把 SSDF 与 SLSA、in-toto、Sigstore 等开源体系正式纳入 NIST 推荐栈，给出了可落地的 CI/CD 安全检查项⁴：

• Build environment attestation：构建环境的清单、隔离、加固；
• Process & material attestation：构建过程证明 + 物料（源码/依赖/配置）证明；
• Build policy enforcement：开发者认证、双人 PR、自动化策略门禁。

SP 800-204D 的特殊性在于，它是第一份在 NIST 官方文件中明确推荐 SLSA 与 Sigstore 的文档，意味着开源社区项目获得了联邦背书——这一点对后续 npm/PyPI 全量铺开 Sigstore 签名是重要的政治信号。

1.4 OMB 备忘录与 CISA 自证表格：把"建议"变成"必须"

EO 14028 的真正"长牙齿"环节是 OMB 备忘录：

• M-22-18（2022-09-14）：要求联邦机构在使用软件前获得供应商基于 SSDF 的自我证明（self-attestation），首次把 SSDF 强制化⁵；
• M-23-16（2023-06-09）：扩展 M-22-18，把范围扩展到所有"重要"自研/采购软件，并允许 CISA 制定通用表格。

CISA 在 2024-03 经 OMB 批准、2024-06 公开发布了 Secure Software Self-Attestation Common Form——一份将 SSDF 关键实践转化为签字表格的标准表单，CEO 或同级高管必须签字确认⁶。这是 EO 14028 执行链最末端、约束力最强的一环：签字代表个人法律责任。

1.5 CISA SBOM：从 NTIA 2021 到 2025 Minimum Elements 升级

EO 14028 4(e) 条款明确要求 SBOM。2021 年 NTIA 发布的 Minimum Elements for an SBOM 列出 7 个最小字段（供应商、组件名、版本、依赖关系、SBOM 作者、时间戳、唯一标识）。2023 年 SBOM 工作组从 NTIA 移交到 CISA，CISA 接管后每季度举办"SBOM-a-rama"线上研讨会，议程聚焦 VEX、SaaS SBOM、加密资产清单（CBOM）、AI BOM 等新场景⁷。

2025-08-22，CISA 发布 2025 Minimum Elements for a Software Bill of Materials 草案，公开征求意见至 2025-10-03⁸。相比 2021 NTIA 版本，2025 草案核心新增字段为：

• 组件 hash——为后续 in-toto、Sigstore 验签提供锚点；
• license——纳入许可证字段，与合规联动；
• 生成工具名 + 生成上下文（generation context）——可追溯 SBOM 是怎么产生的；
• 首次纳入 SaaS 与 AI 模型场景——AI BOM 进入正式字段考虑范围。

至此，美国从 EO 到字段标准的链条全部闭合：EO 14028（2021）→ NIST SSDF（2022）→ M-22-18 / M-23-16（2022/2023）→ NIST SP 800-204D（2024-02）→ CISA Self-Attestation Common Form（2024-06）→ CISA 2025 SBOM Minimum Elements（2025-08 草案）。每一步约束力都在递增，从"建议"逐渐爬升到"高管签字担责"。

二、欧盟：CRA 是全球第一份"软件硬强制"法规

如果说美国是"行政令 + 自证"组合拳，欧盟则直接走"产品监管"路径——把软件视为带 CE 标志的工业品，纳入产品责任体系。

2.1 Cyber Resilience Act：全球首部强制 SBOM 的法规

Cyber Resilience Act, Regulation (EU) 2024/2847，是迄今为止全球约束力最高的软件供应链法规。

立法过程：欧委会 2022-09 提案 → 2023-12 三方协议 → 2024-03 欧洲议会通过 → 2024-12-10 在欧盟官方公报刊登并即日生效⁹。

CRA 完整时间表

CRA 核心义务

1. 安全设计：必须满足 Annex I 列举的网络安全基本要求（密码默认强度、身份认证、漏洞处理流程等）；
2. 结构化 SBOM：CRA 是全球首部以法规形式强制 SBOM 的法律，要求按机器可读格式（CycloneDX 或 SPDX）维护并向监管机构提供；
3. 协调披露策略：必须公开自由可用的漏洞披露策略；
4. 至少 5 年漏洞维护期——这一条对消费类硬件冲击最大，过去 IoT 厂商往往在产品发布 18 个月后就停止维护；
5. 合格评定（Conformity Assessment）：一般 PDE 可自我评估，关键 PDE 必须由第三方公告机构评估——例如操作系统、密码库、工业控制器等。

对开源的影响

CRA 立法过程中开源界最关心的"维护者会不会变成强制责任主体"问题，经长期博弈后达成的折中方案：非商业行为的开源贡献者豁免；但商业打包/集成厂商（如 Red Hat、SUSE、Canonical）仍受约束。OpenSSF 公共政策办公室在 2023–2024 年期间持续在欧盟立法过程中代表生态发声¹⁰。

与软件投毒的直接关系

CRA 强制 SBOM + 漏洞跟踪意味着：**任何把 PyPI/npm 包打入产品的厂商，都必须有能力溯源恶意包并及时通报。**对 EU 市场而言，CRA 可能成为 2027 年后所有 SCA / SBOM 工具采购的最强推动力。

2.2 ENISA Threat Landscape：把供应链列入七大头部威胁

ENISA Threat Landscape 是欧盟年度网安态势报告，ETL 2024（覆盖 2023-07 至 2024-06）于 2024-09 发布¹¹。报告把"供应链攻击"列为七大头部威胁之一（与 DDoS、勒索、数据攻击、恶意软件、社会工程、信息操纵并列），并指出供应链已成为水平面威胁，与其他威胁交叠出现——也就是说，攻击者不再单纯做供应链攻击，而是把它作为初始访问手段嵌入到勒索软件、APT 等链路中。

ETL 2024 反复引用的两个标志性案例：

• xz-utils（CVE-2024-3094，2024-03 披露）：长期社工 → 接管开源维护权 → 投放后门，被 ENISA 称为"开源供应链最完美的攻击范本"；
• 3CX 桌面应用木马（2023）：第一起以 SaaS 厂商为跳板的"双层供应链攻击"。

ENISA 还有更专题的 Threat Landscape for Supply Chain Attacks 专项报告，专门跟踪供应链攻击模型与防御建议。

2.3 NIS2：把"上游被投毒"视为运营者责任

NIS2 Directive (EU) 2022/2555 已于 2024-10-17 由成员国转法。它要求"必要实体（essential）"和"重要实体（important）"开展供应链风险管理（Article 21(2)(d)）。

CRA 与 NIS2 的分工很清晰：

• NIS2 管"运营者使用软件的安全"——你用了什么软件、怎么管，是运营者责任；
• CRA 管"软件本身的安全"——软件是否安全，是制造商责任。

两者互补。从软件投毒的角度看，NIS2 把上游开源被投毒视为运营者必须管理的风险源，明确鼓励使用 SBOM、Scorecard 等工具识别上游可信度——这给了 OpenSSF 项目一个法律层面的"用户拉动力"。

三、英国：Code of Practice 走"原则化"路线

英国的路径与美国、欧盟都不同：既不像美国那样靠 EO + OMB 强行推 SSDF，也不像欧盟那样直接用法规罚款，而是延续 NCSC 一贯的"原则化指南"风格。

3.1 NCSC 供应链安全 12 项原则

英国国家网络安全中心（NCSC，归属 GCHQ）的供应链安全专题集已有多年积累¹²，内容包括：

• 12 项供应链安全原则；
• 与 ISO/IEC 27036 的映射；
• 对中小供应商的最低要求清单。

在开源供应链方面，NCSC 长期推荐 SLSA 与 OpenSSF Scorecard 作为评估上游开源项目可信度的工具——这是 OpenSSF 项目少数获得国家级安全机构推荐的样例。

3.2 Software Security Code of Practice：2025-05-07 正式发布

由 DSIT（数字、文化、媒体和体育部）联合 NCSC 制定的 Software Security Code of Practice，2024-05 发布草案征询，2025-05-07 在 CyberUK 2025 大会上由内阁大臣 Pat McFadden 正式发布最终版¹³。

主要变化：原 21 项细则精简到 14 项高层原则，覆盖安全设计、供应链管理、漏洞披露、客户沟通、安全更新等。由加拿大网安中心（CCCS）联署，这意味着它在英联邦层面具有跨国采纳趋势——加拿大、澳大利亚、新西兰未来很可能在自己的政府采购流程中引用这份文件。

约束力上：与美国 SSDF 相比更"原则化"、更接近 NCSC 一贯指南风格；与欧盟 CRA 相比是自愿遵循——英国脱欧后选择了一条"软引导"的路径，主要靠采购话语权与行业声誉机制驱动遵循。

四、基金会与社区：OpenSSF 项目矩阵就是事实标准库

如果说政府文件提供"约束力"，那么基金会项目则提供"工具栈"。这一节把 OpenSSF、Linux Foundation Project Census、CNCF TAG-Security 三家最有影响力的开源治理组织拼在一起。

4.1 OpenSSF：项目矩阵已成全球事实标准

Open Source Security Foundation 隶属 Linux Foundation，2020 年由 GitHub OSS Security Foundation 与 Core Infrastructure Initiative 合并而来；目前由 Google、Microsoft、AWS、Intel、Red Hat 以及华为、阿里、字节、腾讯等顶级会员资助¹⁴。

OpenSSF 旗下重点项目矩阵（按用途分类）：

其中 Scorecard 是被引用最多的——CISA 也将其列入推荐工具，GitHub Dependabot 自 2024 年起把 Scorecard 分数集成到 PR 评估指标中。Sigstore 则是 npm 在 2023 年、PyPI 通过 PEP 740 在 2024 年采用的签名底座，事实上已成为开源签名的"水电煤"。Package Analysis 流水线产出的恶意包数据通过 ossf/malicious-packages 仓库开放分发，是国内外多家 SCA 厂商的免费情报源。

OpenSSF 公共政策办公室在 2024–2025 年期间还在 CRA、CISA SBOM Minimum Elements、白宫安全开发自证等流程中代表生态发声，是开源社区与立法者之间最重要的桥梁组织。

4.2 Linux Foundation Project Census：用数据验证哪些组件最关键

Census of Free and Open Source Software 系列报告由 LF Research 与哈佛 LISH 合作，最近一期 Census III（2024-04）盘点了企业最常用的开源组件，并指出"npm/PyPI 中无版本约束的 dev-dependency"是主要风险点¹⁵。这份数据的价值在于，它给"哪些项目应该优先获得 Alpha-Omega 资助"提供了数据底座。

4.3 CNCF TAG-Security：云原生场景的供应链共识

CNCF 安全 SIG（TAG-Security）持续维护 Software Supply Chain Best Practices 白皮书；其分支 Catalog of Supply Chain Compromises 收录历史投毒事件作为教材。关注重点：

• K8s 镜像签名（cosign 集成）；
• ArgoCD GitOps；
• Helm Chart provenance。

TAG-Security 的特殊价值是在云原生场景把 SLSA/Sigstore 的概念落地——例如 ArgoCD 拒绝部署未签名镜像的策略模板就出自 TAG-Security 的工作组讨论。

五、大厂实践：Google、Microsoft、AWS、GitHub 的内部战略

政府文件与基金会项目最终要落到执行——这一节聚焦四家大厂的供应链战略层动作（细到 SCA 工具特性的对比留给本系列第 03、05 篇）。

5.1 Google：把 BAB 内部经验产品化为 SLSA + deps.dev

Google 的特殊性在于，它的供应链安全不是"立项做的"，而是"沉淀出来的"。

• SLSA 起源：脱胎于 Google 内部的 Binary Authorization for Borg (BAB)，BAB 已在 Google 生产 8 年以上，要求所有进入 Borg 集群的二进制都必须有可验证 provenance¹⁶。SLSA 等级体系本质上就是 BAB 的对外抽象。
• deps.dev / Open Source Insights：Google 维护的开源依赖图与漏洞元数据 API，提供 SBOM 友好的 REST/BigQuery 接口，集成 Scorecard 分数、依赖深度、license、OSV 漏洞。
• OSV.dev：开源漏洞数据库，schema 已成事实标准，与 GitHub Advisory、PyPI/npm 漏洞数据库互联。
• Assured OSS：Google Cloud 商业产品，把 1000+ 重要 Java/Python 包重新构建、签名、扫描后再分发——这是大厂"自己当镜像源"的代表实践。
• OSS-Fuzz：模糊测试基础设施，已为数百个核心开源项目发现数千漏洞。

Google 的共同特点是：所有项目都先在内部跑几年，验证规模化可行后再开源，这与 Microsoft 的"启动即喊口号"风格形成鲜明对比。

5.2 Microsoft：Secure Future Initiative 六支柱

Microsoft 在 2023-11 启动 Secure Future Initiative (SFI)，被官方称为"史上最大网安工程"；2024-05 扩展为六大支柱并投入约 34000 人年¹⁷。其中"保护软件供应链"是六支柱之一¹⁸，下设三个子能力：

• Component Governance (CG)：内部 SCA 工具，自动识别开源依赖中的漏洞与许可风险；
• Centralized Feed Service (CFS)：自建私有镜像，对入站包做反恶意、反 typosquat、隔离新版本——这是把"自己当镜像源"做到极致的实践；
• Governed Pipeline Templates：标准化 YAML，强制 SBOM 生成、SAST、双人签字、代码签名。

2025-08 微软发布 SFI Patterns & Practices 实战指引，2025-10 又发布更细化模式¹⁹。截至 2025-11 进展：85% 商业云产品的生产构建流水线已使用集中治理的 YAML 模板——这一指标的真正意义是，巨型组织（数十万工程师）的供应链统一治理是可行的。

5.3 AWS：CodeArtifact + Inspector + Signing

AWS 的供应链方案以"产品化、可被客户消费"为目标：

• CodeArtifact：托管包仓库，支持 npm、PyPI、Maven、NuGet、Swift、generic 等。2024 起接入 Inspector 自动扫描托管工件；
• Inspector：漏洞与软件成分分析服务，已扩展到容器镜像（ECR）、Lambda、CI 构建产物，并产出 CycloneDX SBOM 输出到 S3；
• Signer + Notation + ECR Image Signing：2024–2025 全面支持容器镜像与 Lambda zip 的签名验证。

AWS 不像 Microsoft 那样大张旗鼓打"安全"品牌，而是把供应链能力嵌入既有云服务。这也意味着，AWS 客户拿到的"SBOM/签名/扫描"是云服务的副产品，而不是独立产品线。

5.4 GitHub：从 Dependabot 到 Artifact Attestations 的战略层动作

本系列第 05 篇详细对比 GHAS 的产品特性，本节侧重战略层：

• GitHub Advisory Database：免费、开放、可贡献的漏洞与恶意包数据库，是 OSV / 主流 SCA 的重要数据源；
• Dependabot：基于 GHSA 数据库的依赖告警，2024 年起把 OpenSSF Scorecard 分数集成到 PR 评估；2026-03-17 GA 的 Dependabot Malware Alerts 把 OpenSSF Malware Streams 的恶意包数据带到了开发者 PR 中；
• GitHub Artifact Attestations（2024-05 GA）：以 Sigstore 为底座，给所有 GitHub Actions 构建产物自动加签名。这一动作与 npm 的 Trusted Publishing（2025-07-31 GA）形成完整闭环——CI/CD 产物在 GitHub 端签名，发布到 npm 端 Sigstore 验签。

GitHub 战略的核心是把自己定位为"开源供应链的公共基础设施"。Microsoft 收购 GitHub 后，原本可能商业化的功能（如 Dependabot、Provenance）大量保持免费，原因正在于此——GitHub 是 Microsoft 在开源世界的"软实力源头"。

六、未来 12–24 个月监管节点（倒计时）

下面这份倒计时以 2026-05-05 作为起点，列出 2026–2028 年间国外软件供应链领域已确定时间表的监管节点——读者可以拿它对齐自己组织的合规路线图。

两个最值得关注的节点是 2026-09-11（24 小时漏洞通报启动）和 2027-12-11（CRA 全面适用）——前者考验厂商的事件响应流程，后者是软件市场准入的硬门槛。任何在欧盟有营收的厂商，都应该把"2027-12-11"写进自己的合规计划里。

下一篇（07）将进入中国视角，看 GB/T 43698-2024 与"123456"体系如何在另一条路径上回应同一道问题。

脚注