对以开源组件构建产品、销往欧洲的中国制造商而言，开源软件合规的主要工作是识别组件许可证，履行开源许可证义务，制定软件物料清单（SBOM）与 NOTICE 文件，这套动作围绕根据开源软件使用场景履行开源许可证义务展开。

2024 年 10 月 23 日，欧洲议会与欧盟理事会通过《网络韧性法案》（Cyber Resilience Act，Regulation (EU) 2024/2847，下称“CRA”），并于2024 年 12 月 10 日生效。这是欧盟首部针对“含数字元素产品”（products with digital elements，下称“PDE”）网络安全的市场准入立法，其核心逻辑是把“默认安全、漏洞处理、上市后报告”从企业的自愿实践变为与 CE 标志绑定的法定门槛。CRA首次在欧盟从产品立法角度中对开源软件的使用要求进行了专门规定，并将这些要求作为产品安全与市场准入的条件。CRA 第 14 条漏洞与事件报告义务自 2026 年 9 月 11 日起适用，其余义务自 2027 年 12 月 11 日起全面适用。对大量使用开源组件构建“含数字元素产品”并销往欧洲的中国制造商来说，开源软件合规策略也应当相应做出调整。

在传统的根据开源软件使用场景履行开源许可证义务的基础上，CRA要求符合规定定义的制造商对开源软件进行安全尽调、持续追踪、漏洞报告和支持期承诺，且形成可供监管查验的证据。

（一）对“含数字元素产品”中使用的开源组件的尽调义务

对“含数字元素产品”中开源组件的尽调义务规定在CRA第 13 条第 5 款，该款要求制造商“在集成第三方来源的组件时应进行尽职调查以确保这些组件不损害产品的网络安全，此规定亦适用于集成在商业活动中尚未在市场上公开提供的自由及开源软件所包含的组件的情况”。

在实际操作层面，尽调通常需要核实组件制造商是否已证明符合本法规，包括检查该组件是否已带有CE标识；核实组件是否定期收到安全更新，例如检查其安全更新历史；核实组件是否不存在根据(EU) 2022/2555号指令第12(2)条设立的欧洲漏洞数据库或其他可公开访问的漏洞数据库中已登记的漏洞；或开展额外的安全测试。制造商在将“含数字元素产品”投放市场时以及支持期内必须遵守的漏洞处理义务，适用于具有数字元素的产品的整体，包括所有集成组件。

在开展尽职调查过程中，如果“含数字元素产品”的制造商识别出某一组件（包括自由和开源组件）中的漏洞，应通知制造或维护该组件的人员或实体，处理并修复该漏洞，并在适用情况下向该人员或实体提供已应用的安全补丁。

履行CRA项下开源组件的尽调义务存在一个现实困难，即上游大量纯社区开源项目不在CRA管辖范围内，缺少配合下游出具尽调文件的动力；而下游制造商的尽调义务又恰恰依赖上游信息。上游没有法律义务配合，下游却有法定义务尽调，两者之间的落差构成开源供应链合规的主要实操难点。对前述难点的解决路径可以考虑：其一，善用公开数据源。CVE/NVD、GitHub Advisory、OSV 等公开漏洞库，以及 NIS2 框架下的欧盟漏洞数据库，可以作为组件漏洞核查的基准，部分替代对上游直接信息的依赖。其二，建立组件健康度评估。维护活跃度、发布频率、安全响应历史、维护者背景等指标应在选型阶段即纳入，以排除“孤儿组件”。其三，对处于关键路径却已停维的组件，果断采取自维护（fork）、购买商业支持或替换的策略，并把决策理由记入技术文档，使尽调与替代决策可追溯。其四，关注上游合规信号。CRA第 25 条授权委员会以委托立法建立自愿性开源软件安全证明项目，允许开源软件开发者、使用者和第三方评估其与基本要求或其他义务的符合性，直接服务于第 13 条第 5 款的尽调。该机制一旦落地，上游项目出具的自愿证明将成为下游尽调的高价值凭证。

（二）制作SBOM 兼顾许可证合规和网络安全义务

CRA附件一第二部分第 (1) 项要求制造商识别并记录产品所含漏洞与组件，包括以常用且机器可读的格式编制 SBOM，至少覆盖产品顶层依赖。

许可证合规实践早已以 SBOM 形式管理组件与许可证信息（常见表达为 SPDX 或 CycloneDX 格式）帮助制造商根据开源组件的使用方式履行相应的许可证义务。而CRA 让同一份SBOM承担第二项功能：作为漏洞识别与响应的基础。换言之，企业若已在过往的开源合规实践中具备 SBOM表，只需在其上补充安全维度字段（包括但不限于组件版本、漏洞状态、更新来源、维护活跃度等）即可同时用于履行CRA与许可证的合规义务。

（三）漏洞报告和支持期承诺义务

CRA第 3 条第 20 款把“支持期”（ support period）定义为制造商须确保产品漏洞按附件一第二部分有效处理的期间。CRA 第 13 条第 8 款规定，支持期原则上至少五年，产品预期使用期不足五年的，支持期与预期使用期一致；支持期的确定因素应记入技术文档，制造商并应建立协调漏洞披露政策。

CRA附件一第二部分第 (2) 至 (8) 项进一步要求：及时修复漏洞并提供安全更新（技术上可行时使安全更新独立于功能更新）、定期开展安全测试、公开披露已修复漏洞信息、执行协调披露政策、提供漏洞报告渠道、以安全机制分发更新。 对中国制造商而言，即使上游开源项目停止维护，五年支持期的义务并不消灭，而是落到集成该组件的制造商身上。企业需要在引入前评估拟使用的开源组件的可持续性，并对关键路径上的停维组件安排自维护（fork）、商业支持或替换。

（四）漏洞补丁回馈义务

CRA第 13 条第 6 款规定的补丁回馈义务是 CRA 中与既有开源实践差异最大的条款之一。该条款要求制造商发现所集成组件（含开源组件）存在漏洞的，应向组件的制造或维护者报告，并依附件一第二部分处理与修复漏洞；制造商如已开发了解决漏洞的软件或硬件修改，应与组件制造或维护者共享相关代码或文档，适当时以机器可读格式提供。

长期以来，使用开源组件的制造商较少向上游主动回馈代码，发现漏洞往往内部修复后不再向上游提供者反馈。CRA 把补丁回馈规定为法律义务，有利于推动开源软件完善和发展。

CRA 对开源软件并不只有增加义务，在合格评定环节规定了对商业化开源项目实质有利的制度安排。CRA第 32 条第 5 款规定，落入附件三（重要产品）类别的开源软件制造商，只要在产品投放市场时公开CRA第 31 条要求的技术文档，即可选用CRA第 32 条第 1 款所列的四种合格评定程序，其中包括基于模块 A 的内部自评程序（制造商自我声明），免于第三方机构介入进行评估，从而可以起到简化流程和成本的作用。

考虑到一个许可证较为宽松却无人维护的组件在 CRA 语境下可能比一个互惠程度要求高但治理健全的组件带来更高的合规成本，CRA 将在一定程度上影响现有开源生态。制造商此前选择开源软件的偏好更侧重于许可证的宽松度、功能和社区规模，CRA生效后，制造商必须将安全治理与可持续性维度纳入选用开源软件的考量范围，包括上游是否有成熟的安全响应机制、是否发布安全公告、能否支撑下游五年的支持期。而这一选择偏好的改变也必然会影响上游开源软件的发布和维护者的策略选择，进而推动开源生态向更合规、更安全的方向发展。

CRA第一个重要日期与报告义务有关。2026 年 9 月 11 日起，CRA第 14 条报告义务适用。

即自 2026 年 9 月 11 日起，制造商知悉其“含数字元素产品”存在被积极利用的漏洞或发生严重影响产品安全的“严重事件”（判定标准见CRA第 14 条第 5款）时，须通过欧盟网络安全局ENISA建立的单一报告平台（SRP）提交通知。

报告的时限要求为，24 小时内提交早期预警，72 小时内提交详细通知。漏洞类事件的最终报告不迟于补救或缓解措施可用后14 天，事件类最终报告在 72 小时通知后 1 个月内提交（参见CRA第 14 条第2款C和第 14 条第 4款）。

制造商还须将风险与缓解措施告知受影响用户（CRA第 14 条第 8款）。特别需要注意的是，依据CRA第 69 条第 3款，这一报告义务适用于法案全面生效前（即2027 年 12 月 11 日前）已投放市场的全部在列产品。

CRA第二个重要日期与全面合规有关。2027 年 12 月 11 日起，CRA全面适用，包括第 13 条第 5、6 款的尽调与补丁回馈、附件一的安全与漏洞处理要求、第 32 条的合格评定，以及 CE 标志与符合性声明义务。过渡期另有两项安排需要留意：2027 年 12 月 11 日前已投放的产品，仅在其后发生实质性修改时才受全面约束，但是前文提及的第14条的规定不受此限制（CRA第 69 条第 3款）；此前依据其他欧盟协调立法取得的网络安全相关型式检验证书或批准决定，其效力延续至 2028 年 6 月 11 日（CRA第 69 条第 1 款）。

欧盟的法律监管将对全球的开源合规实践带来“布鲁塞尔效应”，对于中国制造商而言，其应把开源组件的安全尽调加入开源软件引入合规流程作为默认前置步骤。其次，中国制造商还应扩展原有的软件产品SBOM字段，在许可证解析基础上扩展CRA要求的安全字段。再次，对开源组件进行台账化管理，为每个开源组件记录许可证、版本、漏洞状态、维护活跃度、安全更新来源，使其成为CRA第 13 条第 5 款尽调的可审计证据。又次，规范化上游协同和漏洞报告流程，按照CRA要求的时限，把“发现漏洞、上报上游、协同修复、补丁回流、履行 CRA 报告”作为规范化业务流程。最后，制定停维开源组件处理策略，对停维开源组件执行自维护或商业支持替代。

CRA 带给中国制造商的开源命题，本质上是一次开源软件安全责任的压实。上游开源项目的自由与松散，不能成为下游产品不安全的理由。开源软件上下游通过实施CRA 成体系的尽调、追踪、报告与回馈措施，将增强社会对开源软件安全性的信任，进而推动整个开源生态向更安全更合规方向完善和发展。