ARTICLE · 980418
产品用了开源软件,出了漏洞谁负责?CRA下厂商不能只把责任推给开源社区
这是企业面对产品漏洞时很常见的一种解释。
一台出口欧盟的网络设备、工业控制系统或智能终端，可能使用 Linux 作为操作系统，使用 OpenSSL 实现加密通信，使用 Log4j 记录日志。
如果这些开源组件曝出漏洞，产品厂商是否可以告诉客户：
代码不是我们写的，漏洞也不是我们造成的，请等待开源社区发布补丁。
在欧盟《网络韧性法案》（Cyber Resilience Act，以下简称 CRA）下，事情没有这么简单。
企业当然可以说明漏洞来自哪个开源组件，但不能因为代码来自开源社区，就免除自己对最终产品的安全责任。
一、CRA并不是要让所有开源开发者负责
讨论这个问题，首先要澄清一个误解：
CRA并没有要求所有开源软件开发者，都像商业产品制造商一样承担完整的合规责任。
一名个人开发者出于兴趣维护开源项目，无偿公开源代码，也没有围绕该软件开展商业活动，通常不会因为某家企业使用了他的代码，就自动成为 CRA 意义上的“制造商”。
这是合理的。
如果一名开发者免费贡献了一段代码，后来被大量商业公司集成到产品中，却要由这名开发者为所有商业产品承担安全责任，开源生态将难以持续。
因此，CRA 关注的不是“代码是否开源”，而是：
这款软件是否在商业活动中被投放欧盟市场？谁将它集成到产品中？最终产品又是以谁的名称或商标销售？
不过，“免费提供”也不一定意味着“不属于商业活动”。
如果一款免费软件与收费服务、商业平台或其他盈利活动存在关联，仍然需要结合具体的提供方式和商业模式进行判断。
二、使用开源组件的商业厂商，仍要对最终产品负责
假设一家中国企业开发了一款网络设备：
• 底层运行 Linux；• 使用 OpenSSL 实现加密；• 使用多个开源库提供 Web 服务；• 最终以自己的品牌销往欧盟。
客户购买的不是几个零散的开源组件，而是这家企业提供的完整产品。
这家企业也就不能仅用“漏洞来自上游开源项目”来结束问题。
CRA 要求制造商在集成第三方组件时采取适当的审慎措施，避免这些组件损害最终产品的网络安全。
换句话说：
漏洞是谁写出来的，与谁要对最终产品负责，是两个不同的问题。
开源社区可能负责维护上游项目，但把组件选择、集成并交付给客户的，是产品制造商。
只要企业以自己的名称或商标将产品投放欧盟市场，就需要评估开源组件给最终产品带来的安全风险，并在产品支持期内持续管理这些风险。
三、开源组件出现CVE，不等于产品一定受影响
企业承担责任，并不意味着某个开源组件一出现 CVE，所有使用该组件的产品都必须立即升级。
同一个漏洞，对不同产品的实际影响可能完全不同。
企业还需要进一步判断：
• 产品是否使用了存在漏洞的组件版本；• 存在漏洞的代码是否被编译进产品；• 产品是否启用了相关功能；• 当前配置是否满足漏洞利用条件；• 漏洞能否通过产品对外暴露的接口被利用；• 产品是否已经存在其他缓解措施。
因此，正确的做法既不是看到高危 CVE 就机械地要求所有客户升级，也不是用一句“这是开源漏洞”便停止处理。
真正重要的是，企业能否给出有技术依据的结论：
哪些产品受到影响？哪些产品不受影响？判断依据是什么？
这也是 SBOM 真正发挥作用的地方。
SBOM 不是为了在合规检查时提交一张漂亮的组件清单，而是为了在漏洞出现后，快速定位受影响的产品、版本和客户。
四、上游没有补丁，厂商也不能停止处理
现实中还有一种更棘手的情况：
开源组件已经曝出漏洞，但上游项目尚未发布补丁，甚至早已停止维护。
这时，产品厂商不能只告诉客户：
“我们正在等待开源社区解决。”
等待可以是处理过程的一部分，但不能成为完整的漏洞处置方案。
企业仍然需要评估能否采取其他措施，例如：
• 临时关闭存在风险的功能；• 修改产品的默认配置；• 增加访问控制或检测措施；• 自行修改代码，并将修复贡献给上游项目；• 替换已经停止维护的组件；• 向客户提供临时缓解方案和安全使用建议。
制造商不一定需要独立修复所有上游代码，但必须管理漏洞对自己产品造成的风险。
如果企业长期依赖无人维护的开源组件，也没有替换、自行维护或风险缓解能力，那么真正的问题就不只是一个漏洞，而是产品的软件供应链缺乏可持续性。
五、CRA还引入了“开源软件管理者”
在普通开源开发者和商业产品制造商之间，CRA 还定义了一类特殊角色：
开源软件管理者（Open-source software steward）。
它通常是一个法人组织，长期、系统地支持特定开源项目，并保障这些项目持续发展和维护。
开源软件管理者不完全等同于产品制造商，但仍需要承担与其角色相适应的义务，例如：
• 建立网络安全政策；• 推动安全开发和漏洞有效处置；• 与市场监管机构合作；• 在满足法定条件时，报告已被主动利用的漏洞或严重安全事件。
这体现了 CRA 对开源生态的基本态度：
既不能把商业产品的全部责任压给普通开源开发者，也不能让从开源软件中获得商业价值的企业完全逃避责任。
六、企业真正缺少的，往往不是一份SBOM
面对 CRA，很多企业首先想到的是购买一套工具，生成一份 SBOM。
但真正需要建立的，是一套完整的开源组件治理机制。
至少应当包括以下五项能力。
1. 知道产品里有什么
记录组件名称、版本、来源、许可证、依赖关系，以及它被哪些产品和版本使用。
2. 持续监测组件漏洞
在产品支持期内持续跟踪 CVE、组件安全公告、开源社区修复信息以及已被主动利用的漏洞，而不是只在产品上市前扫描一次。
3. 分析漏洞的实际影响
结合产品架构、配置、功能和攻击面，判断漏洞是否真正影响产品，并保存相应的判断依据。
4. 建立修复和替代方案
针对仍在维护、已经停止维护以及短期内无法升级的组件，分别制定升级、缓解、自行维护或替换方案。
5. 保存全过程证据
企业需要能够证明：
什么时候发现漏洞，如何判断影响，采取了什么措施，什么时候发布更新，是否通知客户，以及是否触发 CRA 报告义务。
七、用五个问题检查企业是否准备好了
企业可以用下面五个问题进行初步检查：
**第一，**能否快速查出某个开源组件被哪些产品和版本使用？
**第二，**能否判断一个 CVE 是否真正影响自己的产品？
**第三，**上游项目停止维护后，有没有替换或自行维护方案？
**第四，**能否在产品支持期内持续向客户提供安全更新？
**第五，**能否拿出完整的评估、决策、修复和通知记录？
如果大部分答案都是“不能”，那么企业缺少的就不只是一份 SBOM，而是一套真正的开源软件风险治理能力。
写在最后
开源软件本身不是问题。
真正的问题，是企业把开源组件当成一种“可以免费使用，出了问题也与自己无关”的零件。
CRA 并不要求企业拒绝使用开源软件，也不要求商业厂商为整个开源生态负责。
它要求的是：
谁把开源组件集成到自己的商业产品中，谁就应当识别、评估和处置这些组件给最终产品带来的安全风险，并能够证明自己已经履行了相应责任。
企业不能把产品责任全部推给开源社区。
同样，商业世界也不应把所有责任不加区分地压给普通开源开发者。
这才是理解 CRA 开源软件责任边界的关键。
参考资料
欧盟《网络韧性法案》正式文本
https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng欧盟委员会：Cyber Resilience Act—Open source
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source欧盟委员会：The Cyber Resilience Act—Summary of the legislative text
https://digital-strategy.ec.europa.eu/en/policies/cra-summary