OSPO 如何帮助组织为欧盟《网络弹性法案》做好准备

来源： Linux 基金会 – 博客
作者： andrewb@proximabiz.com（Linux 基金会）
发布时间： 2026/9/10 03:11:24
原文链接： https://www.linuxfoundation.org/blog/how-ospos-are-preparing-organizations-for-the-eu-cyber-resilience-act

---

对于在欧盟提供含数字元素产品的组织而言，下一个重要的《网络弹性法案》（Cyber Resilience Act，CRA）截止日期将于 2026 年 9 月 11 日到来。从该日期起，受报告义务约束的组织必须准备好评估已被积极利用的漏洞和严重安全事件，协调内部响应，并在规定时限内提交通知。

然而，许多组织可能并不清楚自己是否需要报告。2026 年 CRA 认知与准备度报告发现，66% 的受访者对 CRA 了解甚少或完全不了解。即便在熟悉该法案的受访者中，也有 41% 尚未确定该法规是否适用于自身。

图片来源：2026 CRA 认知与准备度报告

当发现一个正在被积极利用的漏洞或一起严重事件时，你的组织能否识别出受影响的产品或项目、调动正确的团队，并协调适当的响应？

开源项目办公室（Open Source Program Office，OSPO）的专业人员正在帮助制造商和开源软件管理组织填补这些实际缺口。本文借鉴 TODO Group 成员组织的行业案例，并结合 OpenSSF 与 OpenChain 的资源，探讨他们支持 CRA 实施的三种方式，以及你的组织该如何入手。

为什么临时应对会带来安全风险

当没有人协调开源管理时，CRA 的实施很快就会变得支离破碎：

• 法务部门解读了义务要求，但缺乏产品层面的依赖信息，或对开源供应链的技术理解。
• 安全团队收到了告警，却无法立即识别出每一个受影响的产品。
• 工程团队了解代码，但可能不清楚应由哪个法律实体或产品负责人来做出监管决策。
• 采购部门追踪商业供应商，但可能看不到通过开发流水线引入的开源依赖。
• 各团队分别联系上游维护者，造成重复请求，并给开源社区带来额外压力。

这些缺口在事件发生期间尤为危险。团队会浪费关键时间，用于验证组件版本、寻找负责人，以及追溯某个依赖是如何进入产品的。

OSPO 专业人员则将这项工作提前：

• 他们帮助在事件发生之前，建立一份涵盖产品、组件、代码仓库、内部负责人和上游关系的共享全景图。
• 他们还将开源背景引入风险评估，帮助团队制定相称的措施，而不会产生不必要的合规工作。

这并不会免除法务、产品或工程团队的责任。相反，OSPO 团队为他们提供了履行职责所需的可靠开源信息与关系网络。

Linux 基金会的《2025 年 OSPO 与开源管理现状》发现，在 116 家设有正式或非正式 OSPO 的组织中，92% 让 OSPO 参与开源安全工作：42% 表示 OSPO 负责做出安全风险决策，50% 表示 OSPO 为相关责任团队提供建议。

将法律义务转化为可操作的响应

OpenSSF 已经将制造商、开源软件管理者和贡献者各自不同的义务，转化为易于理解的指南。其《CRA 开源软件开发者简明指南》解释了 CRA 涵盖哪些产品和活动，以及当一个组织成为制造商或开源软件管理者时会发生哪些变化。OpenSSF 和 Linux Foundation Education 还提供免费的 90 分钟课程《理解欧盟网络弹性法案（LFEL1001）》。

如需更详细的实施指导，《OpenSSF 开源软件管理者义务清单》将 CRA 第 24 条（该条确立了开源软件管理者的义务）转化为关于网络安全政策、报告、合作和纠正措施的问题。《CRA 管理者手册》帮助管理者梳理其项目、安全联系人、CSIRT（计算机安全事件响应团队）、开发基础设施和报告流程。对于个人维护者和开发者，《CRA 维护者与开发者准备指南》提供了自愿性的安全与透明度实践，帮助项目支持下游用户，同时不会将 CRA 义务或责任转移给维护者。

对于制造商和产品安全团队，《OpenSSF PSIRT 义务清单》（PSIRT，产品安全事件响应团队）侧重于漏洞和事件报告所需的流程与证据。《OpenChain CRA 要求与清单 RC1》帮助组织将其现有活动和证据映射到 182 个审查要点，涵盖治理、SBOM（软件物料清单）质量、漏洞处理、开源管理和技术文档。

OSPO 专业人员可以入手的三个领域

CRA（网络弹性法案）准备工作并不总是需要新流程。对许多组织而言，它始于将既有的开源、安全和质量管理实践映射到 CRA 要求，记录已有内容并识别剩余差距。

这不需要新的监管部门或复杂结构。可以把 OSPO（开源项目办公室）理解为使组织能够有效管理开源的人员、技能和实践。在跨国公司中，这可能涉及一个专门团队。在较小的组织中，可能是由一个人在其他工作之外协调开源职责。

将产品与组件关联

许多 OSPO 已经维护软件清单或生成 SBOM（软件物料清单）以进行开源许可证合规。CRA 准备可以在此基础上开展，但生成 SBOM 还不够。

ENISA（欧盟网络安全局）的 SBOM Adoption State of Play 2026 发现，尽管 78% 的受访组织已开始采用 SBOM，但只有 9% 达到了成熟、完全自动化的实施。大多数受访者不知道其组织内部是否或如何使用 SBOM。

为支持漏洞处理，组件信息必须跨产品组合和开发生命周期（包括已发布版本、内部修改、产品负责人和支持周期）连接起来，并保持对需要它的团队可访问。OSPO 专业人员可以帮助建立这种共享视图，并解决未识别软件包、私有分支和归属不清等差距。

测试报告链路

当漏洞被积极利用时，产品安全和法务需要快速答案：该组件是否存在？受影响功能是否被使用？组织是否修改过它？谁可以安全地联系上游？

OSPO 提供组件和社区背景，而 PSIRT（产品安全事件响应团队）评估安全影响并确定监管行动。OpenSSF PSIRT Obligations Checklist（OpenSSF，即开源安全基金会）有助于识别产品安全团队所需的流程和证据。组织应通过桌面演练测试完整的 24 小时工作流，而不是等待真实事件发生。

这些演练还可以揭示代理式工作流（agentic workflows）可以在哪些环节减少人工工作。例如，通过收集组件证据、识别负责人并为人工审查准备漏洞案例。

“当足够的自动化已经到位，并且可以通过 API（应用程序接口）获得可靠、高质量的数据时，代理式工作流可以帮助 OSPO。”

– Cornelius Schumacher, DB Systel

同样重要的是，仅有数据质量还不够。正如 Oscar Valenzuela（曾任 Amazon OSPO）在向 TODO Group（TODO 集团）的 Agentic AI to Empower OSPOs Working Group 所做的合规自动化演示中强调的那样，AI 自动化依赖于正确的数据。因此，人工批准、可追溯来源和确定性策略检查仍然至关重要。该工作组正在探索可复用工作流、评估以及这项工作的人在回路边界。

协调上游参与

CRA 不应导致数百家制造商向同一批志愿者维护者发送重叠的问卷。OSPO 专业人员可以整合请求、复用公共项目信息、协调负责任披露，并帮助工程团队向上游贡献修复。

“OSPO 还可以帮助识别关键依赖背后的开源项目，这些项目是资金支持的有力候选。”

– Jeff Luszcz, GitHub OSPO

这为制造商提供了更好的证据和更易维护的软件，同时保护开源社区有限的能力。在整个生态系统中开发的共享、机器可读方法，将比各公司单独流程更具扩展性。

行业经验

以下是 OSPO 专业人员在其组织内领导的一些举措示例。

Nokia

在 Nokia，二十多年的开源合规工作和十年的 OSPO 经验为 CRA 实施提供了基础。Nokia 于 2024 年启动了专门的 CRA 合规计划。Gergely Csatari 是 Nokia OSPO 团队成员，专注于开源政策，他帮助将软件透明度转化为实际工作。

“Nokia 的 OSPO 正在帮助组织在另外三个领域实现 CRA 合规：自动化开源尽职调查、与上游社区协调漏洞修复，以及识别 Nokia 管理哪些已发布项目。”

– Gergely Csatari, Nokia OSPO

• 自动化开源尽职调查：OSPO 协助将诺基亚现有的开源组件选择标准转化为符合 CRA 的开源组件尽职调查计划。由于所消费的开源组件数量庞大且开发速度极快，尽职调查检查完全自动化，基于 Open SSF 的 Scorecard 项目，并集成到诺基亚自主开发的开源合规工具中。CRA 和协调标准并未完全明确尽职调查的所有细节，因此诺基亚 OSPO 团队与其他行业专家一起，正在 ORC 工作组 中致力于编写一份行业统一的尽职调查白皮书。
• 与上游项目协调修复：根据 CRA，诺基亚将有义务向公司发现的上游社区提供零日漏洞的修复。以帮助上游社区而非给维护者造成过重负担的方式进行修复，是诺基亚 OSPO 的职责。开源团队正在为开发和安防团队准备关于开源关键漏洞修复的额外培训，并将现场协助这一过程。
• 识别托管项目：开源软件托管方将有义务报告其托管开源项目中已被积极利用的漏洞，前提是该漏洞位于托管方开发的领域内。为此，诺基亚团队正在积极对已发布的开源项目进行分类。具有活跃开发和维护的项目将被明确声明为诺基亚托管项目，而学术出版物、黑客松示例及其他未维护的项目将被明确标记为非托管项目。

Cisco

在 Cisco，OSPO 将其角色描述为管理公司的开源工作，包括贡献和合规。Cisco 开源首席架构师 Natali Vlatko 强调，在组织应对 CRA 时，从一开始就让 OSPO 参与开源安全至关重要。早期参与可以防止组件所有权和上游关系在后期成为紧急问题。

Deutsche Bahn

Deutsche Bahn 拥有公开的 开源宣言、政策、项目和联系方式。这些实践通过连接项目治理、内部团队和上游社区，为组织奠定了 CRA 准备的基础。它们帮助 DB 确定其支持哪些开源项目，记录这些项目的管理方式，并将安全问题导向适当的人员。

Samsung SDS

另一个例子是 Samsung SDS，它提供了与 CRA 实施相关的开源流程的具体示例。自 2023 年以来，该公司已为其解决方案自动生成、存储和管理 SBOM，用于识别软件供应链关系并分析安全漏洞。2024 年，该公司还宣布符合 OpenChain ISO/IEC 18974，该标准要求具备识别开源组件中已知漏洞、评估其风险并记录修复的流程，有助于支持 CRA 对组件文档和持续漏洞处理的要求。

结语

每个组织都可以在不创建大型部门的情况下应用 OSPO 实践。迫切的要求是明确责任人，赋予他们授权，并将他们的工作与法务、安全、工程和产品领导层联系起来，而且组织不需要独自设计这项工作的每一个部分：

• OpenSSF 的 CRA 资源中心 提供了一条落实 CRA 要求的实用路径。
• 开源项目安全基线（Open Source Project Security Baseline） 为开源项目提供了可度量的安全实践，而 ORBIT 则聚焦于互操作性与工具化，使评估和证据管理更易规模化。
• OpenChain 的 CRA 要求与检查清单 RC1 将 CRA 准备工作拆解为 182 个审查要点，涵盖治理、SBOM 质量、漏洞处理、第 14 条报告、开源治理（stewardship）以及技术文档。RC1 现已开放公众评审，针对 1.0 版本的反馈意见征集截止日期为 2026 年 9 月 8 日。1.0 版本计划于 9 月 11 日发布，初期将聚焦于报告就绪度，随后持续推进，力争在 CRA 于 2027 年 12 月全面适用之前完成 2.0 版本。各组织可通过 GitHub 参与贡献。该检查清单旨在支持就绪度评估与证据管理；完成检查清单本身并不构成合规评估，也不构成法律意见。
• CRA 简明指南（CRA Brief Guide） 与 LFEL1001 课程 帮助开发者、管理者和 OSPO 专业人员建立共同的认知基础。
• TODO Group 的 OSPO 手册中关于管理开源安全的章节 将这些安全专业知识与组织实践连接起来。该章节由 OpenSSF 代表共同参与编写，并获得了 TODO Group 的支持。TODO Group 成员和 OSPO 负责人也在各兄弟项目（OpenSSF、OpenChain、CHAOSS 等）中贡献实践经验，帮助将共享资源转化为开源管理与运营的落地能力。

一个已经梳理清楚自身产品、组件及其上游关系的组织，只需数小时就能回答一项报告相关问题。而尚未完成这项工作的组织，则只能在时限不断逼近的同时，临时拼凑这张关系图。

关于 TODO Group

TODO Group 是一个开放、厂商中立的 OSPO 从业者社区，致力于分享开源管理以及新兴 AI 治理在真实组织环境中的最佳实践。TODO Group 由 Linux 基金会托管，通过创建共享资源与指南，支持各组织之间的实践采用、协同一致与协作。

关于 OpenSSF

开源安全基金会（Open Source Security Foundation，OpenSSF） 汇聚了致力于提升开源软件安全性的个人与组织。它由 Linux 基金会托管，负责制定实用指南、培训课程、工具以及共享安全标准。

关于 OpenChain

OpenChain 项目 为软件供应链制定开源合规与安全保障规范、参考资料及采用资源。其规范是 ISO/IEC 5230 和 ISO/IEC 18974 的基础，该项目由 Linux 基金会托管。

本文贡献者：

• Madalin Neag，OpenSSF 欧盟政策顾问
• Ana Jiménez Santamaría，Linux 基金会高级项目经理
• Gergely Csatari，诺基亚高级开源专家
• Meixia Wang，OpenChain 项目执行总监
• Jeff Luszcz，GitHub OSPO
• Cornelius Schumacher，DB
• Daniel Park，三星 OSPO 经理