一、序言
对以开源组件构建产品、销往欧洲的中国制造商而言，开源软件合规的主要工作是识别组件许可证，履行开源许可证义务，制定软件物料清单（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要求符合规定定义的制造商对开源软件进行安全尽调、持续追踪、漏洞报告和支持期承诺，且形成可供监管查验的证据。
（一）对“含数字元素产品”中使用的开源组件的尽调义务
对“含数字元素产品”中开源组件的尽调义务规定在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对开源软件并不只有增加义务，在合格评定环节规定了对商业化开源项目实质有利的制度安排。CRA第32条第5款规定，落入附件三（重要产品）类别的开源软件制造商，只要在产品投放市场时公开CRA第31条要求的技术文档，即可选用CRA第32条第1款所列的四种合格评定程序，其中包括基于模块A的内部自评程序（制造商自我声明），免于第三方机构介入进行评估，从而可以起到简化流程和成本的作用。
考虑到一个许可证较为宽松却无人维护的组件在CRA语境下可能比一个互惠程度要求高但治理健全的组件带来更高的合规成本，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款）。
五、中国制造商CRA合规建议
欧盟的法律监管将对全球的开源合规实践带来“布鲁塞尔效应”，对于中国制造商而言，其应把开源组件的安全尽调加入开源软件引入合规流程作为默认前置步骤。其次，中国制造商还应扩展原有的软件产品SBOM字段，在许可证解析基础上扩展CRA要求的安全字段。再次，对开源组件进行台账化管理，为每个开源组件记录许可证、版本、漏洞状态、维护活跃度、安全更新来源，使其成为CRA第13条第5款尽调的可审计证据。又次，规范化上游协同和漏洞报告流程，按照CRA要求的时限，把“发现漏洞、上报上游、协同修复、补丁回流、履行CRA报告”作为规范化业务流程。最后，制定停维开源组件处理策略，对停维开源组件执行自维护或商业支持替代。
CRA带给中国制造商的开源命题，本质上是一次开源软件安全责任的压实。上游开源项目的自由与松散，不能成为下游产品不安全的理由。开源软件上下游通过实施CRA成体系的尽调、追踪、报告与回馈措施，将增强社会对开源软件安全性的信任，进而推动整个开源生态向更安全更合规方向完善和发展。
原标题：研究|欧盟《网络韧性法案》（CRA）对中国制造商开源软件合规的影响
来源：云上锦天城
作者：
- 丁华，锦天城律师事务所高级合伙人；邮箱：dinghua@allbrightlaw.com
- 陈岱源，锦天城律师事务所律师，邮箱：jinyi@allbrightlaw.com
声明：本文内容仅为提供信息之目的由作者/锦天城律师事务所制作，不应视为广告、招揽或法律意见。阅读、传播本文内容不以建立律师－委托人关系为目的，订阅我们的文章也不构成律师－委托人关系。本文所包含的信息仅是作为一般性信息提供，作者/锦天城律师事务所不对本文做日常性维护、修改或更新，故可能未反映最新的法律发展。读者在就自身案件获得相关法域内执业律师的法律意见之前, 不要为任何目的依赖本文信息。作者/锦天城律师事务所明确不承担因基于对本文任何形式的使用（包括作为或不作为）而产生的一切责任、损失或损害。