目录
欧盟网络弹性法案(CRA)——法规 (EU) 2024/2847——要求在欧洲销售的每一个"具有数字元素的产品"必须提供SBOM。从2027年12月11日起,制造商(包括软件发布商)必须生成机器可读的SBOM,至少覆盖顶层依赖项,保持其最新状态,并在监管部门要求时提供。违规可能触发最高1500万欧元或全球营业额2.5%的罚款。本文深入解析CRA的真实要求,对比美国SBOM做法,回答四个实践者问题,并展示SafeDep开源工具Vet的适用之处。
引言
欧盟的网络弹性法案(CRA)是一项旨在提高具有数字元素的产品网络安全性的新法规。它对硬件和软件产品提出了强制性的安全要求,要求制造商(以及其他将产品投放欧盟市场的主体)在整个产品生命周期内确保安全。从物联网设备到软件应用,CRA致力于解决当前许多产品安全不足以及缺乏及时更新的问题。对软件供应商而言,CRA引入了为产品生成软件物料清单(SBOM)的义务:本质上是软件组件的"成分清单"。这很重要,因为它推动供应商保持对第三方组件和已知漏洞的透明度,这反过来有助于监管机构和客户信任产品是安全构建和维护的。
CRA立法时间线
要理解CRA的历程和合规截止日期,让我们看看从提案到执法过程中的关键里程碑。下表重点介绍了CRA的立法时间线及其条款生效的时间:
| 日期 | 里程碑 |
|---|---|
| 2022年9月15日 | 欧盟委员会提出网络弹性法案。 |
| 2023年12月1日 | 欧盟立法者就最终CRA文本达成政治协议。在社区反馈后引入开源豁免(例如"开源软件管家"概念)。 |
| 2024年3月 | 欧洲议会正式批准CRA。 |
| 2024年10月10日 | 欧盟理事会通过CRA法规。 |
| 2024年12月10日 | CRA在欧盟官方公报上公布;20天后生效(2024年12月30日)。 |
| 2026年9月11日 | 早期义务开始 - 某些CRA条款(如漏洞报告要求)在生效后21个月成为强制性要求。制造商必须在该日期前准备好向欧盟当局(ENISA)报告被利用的漏洞。 |
| 2027年12月11日 | 全面执行 - 所有CRA要求(包括SBOM条款)在36个月过渡期后适用。从该日期起投放欧盟市场的产品必须完全合规(否则将被禁止进入市场)。 |
该时间线允许三年的过渡期,因此组织有直到2027年12月的时间来达到完全合规,其中一些要求(特别是漏洞披露流程)会在2026年9月提前生效。
网络弹性法案中的SBOM——法律规定
CRA对软件生产者最重要的要求之一是软件物料清单(SBOM)要求。以下是CRA文本中SBOM的定位和要求的详细说明:
- 定义: CRA将**"软件物料清单"定义为"一份正式记录,包含具有数字元素的产品软件元素中所含组件的详细信息和供应链关系"。换句话说,SBOM枚举了构成产品的软件组件(库、模块、包等)。
- 生成SBOM的义务: 根据第13条第1款(h)项及附件I第二部分(1),制造商必须"识别并记录产品中包含的组件,包括以常用且机器可读的格式编制软件物料清单,至少覆盖产品的顶层依赖项"。 这本质上要求一份列出产品直接使用的软件组件的SBOM。 值得注意的是,仅列出顶层依赖项是最低要求。法律并未明确要求包含嵌套的子组件,这令担心披露深层依赖树的供应商松了一口气。(但是,正如我们将讨论的,包含更多细节可能是安全方面的最佳实践。)
- 无公开披露要求: 重要的是,CRA明确规定,"制造商不应被强制公开SBOM"。欧盟立法者承认SBOM可能包含敏感信息(例如披露专有组件或潜在漏洞),因此不会强制要求公开发布。
- 未来可能的SBOM标准: 欧盟委员会被授权通过实施法案更具体地规定SBOM格式和要素。CEN/CENELEC研讨会记录(2025年4月)确认,一份横向标准草案将在2026年年中细化附件I的要求——包括SBOM模式。目前,法律没有规定特定格式如SPDX或CycloneDX,但确实要求"常用、机器可读的格式"。 关键要点是确保您的SBOM是结构化的和数字化的(不仅仅是PDF格式的组件列表)
- 按要求向当局提供SBOM: 欧盟的市场监管部门可以要求提供SBOM以检查合规性。制造商必须能够在监管机构"合理解释请求"时提供SBOM。这强调SBOM主要被视为监管透明度工具。 您不必自动与每个客户分享,但您需要准备好供检查。
- 安全重点: CRA的文本明确表示,SBOM旨在提高网络安全。鉴于条款指出,SBOM"帮助制造商和用户追踪新出现的漏洞和网络安全风险"。法律将SBOM定位为使当局获得态势感知和促进漏洞管理的工具(例如,如果一个库被公布存在新的关键缺陷,拥有SBOM的人可以快速识别他们是否使用了该库)。
CRA的范围——谁被覆盖(谁被豁免)
CRA的范围很广——它覆盖几乎所有投放欧盟市场的"具有数字元素的产品",无论是硬件还是软件,只要它们与设备或网络有任何直接或间接连接。这包括计算机、物联网设备、软件包等明显的项目,但也包括不太明显的产物,如固件、操作系统、商业发行的开发者库等。如果您是在欧洲销售数字产品的制造商或开发商,CRA很可能适用于您。
也就是说,法律划出了一些重要的豁免和澄清:
- 开源软件(非商业性): CRA通常不适用于不作为商业活动一部分营销的自由和开源软件。这意味着开源项目或免费发布代码的开发商不在范围内。其理由是避免阻碍开源协作。
但是,如果开源组件被集成到商业产品中,该产品的制造商负责其安全(尽管开源作者不直接承担责任)。
此外,将作为具有数字元素的产品作为自由和开源软件组件提供给他人集成到自己的具有数字元素的产品中,应仅在其原始制造商将该组件货币化的情况下,才被视为在市场上提供。 最终文本甚至引入了"开源软件管家"的概念,用于组织以结构化方式支持开源项目的情况,但这些管家只有轻微义务(如维护安全策略),不承担与制造商相同的责任。 考虑到对许多作为自由和开源软件且已发布但不在本法规意义上投放市场的具有数字元素的产品在网络安全方面的重要性,以持续方式为旨在用于商业活动的此类产品开发提供支持,并在确保这些产品可行性方面发挥主要作用的法律人员(开源软件管家),应受轻触式和量身定制的监管制度约束。
- 高度监管的部门: 产品已受到同样严格的欧盟网络安全规则约束的,基本被豁免以避免重复监管。例如,医疗器械、汽车、航空产品和军事设备免于CRA,因为这些领域有自己的法律涵盖产品安全和安保。
豁免包括某些已受现有规则约束的开源软件或服务产品,例如医疗器械、航空和汽车。
- 软件即服务(SaaS)和云服务: 纯服务通常不在CRA范围内。CRA针对的是投放市场的产品(有形的或可下载的)。云服务和SaaS产品如果没有分发有形产品,则由网络与信息安全指令2(NIS2)处理。 因此,如果您运营云软件服务而不向客户提供软件安装,CRA要求(如SBOM)不直接适用。但是,如果您作为服务的一部分交付任何客户端软件或设备,则该交付的组件将受CRA约束。
实践者的开放性问题(以及SafeDep的观点)
即使手头有立法,实践者在日常实施SBOM要求方面仍面临一些未解决的问题。以下是四个紧迫问题,以及SafeDep对每个问题的观点:
我们的SBOM中究竟需要包含什么才能满足CRA?
法律至少要求顶层组件,但没有列出具体字段。目标是包含您为任何健壮SBOM所需的"最低要素"。至少列出每个软件组件名称、版本和供应商,理想情况下还要列出依赖关系。使用CycloneDX或SPDX等标准格式将固有地覆盖关键字段(组件ID、版本、关系、许可证等)。虽然CRA说仅限顶层,但要考虑在可行的情况下捕获更深的依赖项。这将改善您的安全态势。
好消息是,当局并不期望详尽的每个嵌套模块和可传递依赖项的完整树;一份产品直接依赖项(第三方库、开源包等)的完整列表将满足要求。
但是,请关注即将出台的欧盟指南——如果您遵循NTIA/NIST的SBOM指南,您很可能超过CRA的基线。
我们应该多久更新一次SBOM
CRA暗示SBOM应作为技术文档的一部分进行更新,但没有规定频率。您应该为每个产品发布或更新生成新的SBOM。在实践中,将SBOM生成集成到CI/CD流水线中是理想的。每个可能投入生产的构建都应生成SBOM,这样您始终知道该版本中的确切组件。此外,如果您修补或热修复某个组件,请相应更新SBOM。监管机构会希望看到您的SBOM是最新的——过时的SBOM几乎和没有SBOM一样糟糕。
许多团队使用工具(如SafeDep的Vet或其他SCA工具)作为构建过程的一部分自动生成SBOM,确保持续可用的SBOM。请记住,SBOM是"技术文档"的一部分,必须在产品上市后保存10年。 因此,将SBOM更新视为开发生命周期的常规部分。
如果某些组件是开源的或来自不提供SBOM的供应商怎么办
换句话说,我们如何处理我们使用的第三方组件的SBOM?
大多数开源组件不会随附其维护者提供的SBOM——您需要自己为其生成条目。使用您的SCA工具识别所有包含的OSS库并将其包含在您的SBOM中(该工具可以拉取名称、版本、许可证等信息)。对于第三方商业软件或二进制组件,向这些供应商请求SBOM;如果他们无法提供,您可能需要将该组件作为"黑盒"处理,但至少将其列为SBOM中的顶层项目。CRA最终是让您——产品制造商——负责了解您的产品中包含什么。
合规将如何实际验证,以及SBOM中的敏感IP怎么办
我们会受到审计吗?监管机构或客户会经常要求SBOM吗?
CRA的执行模式可能是抽查或事件驱动。除非发生安全事件或随机审计,否则您可能永远不会被要求提供SBOM。但是,从2027年12月起,您应该假设监管机构随时可能要求您提供SBOM以验证您是否满足要求。
在适用的情况下,软件物料清单,在市场监管部门合理解释请求的情况下提供,且该请求对于该部门能够检查其是否符合附件I所载的基本网络安全要求是必要的。
CRA不会强制您披露源代码或深层设计秘密——仅披露软件组件的身份。如果您担心机密性,请注意当局必须对SBOM信息保密,并且仅在欧盟层面分享汇总的匿名依赖项数据。
SafeDep Vet:CRA对齐的SBOM生成和策略即代码
SafeDep的开源工具Vet旨在为准备CRA等法规的团队简化SBOM和合规管理。SafeDep Vet可以自动生成标准格式的SBOM(包括CycloneDX支持),作为构建流水线的一部分,确保您为每个发布都有最新的SBOM。这很简单:
vet scan -D ./project/ --report-cdx=sbom.json此外,Vet提供策略即代码功能,允许您编码合规规则和安全策略(例如,"不存在高严重性漏洞"或"产品中不存在GPL许可的组件"),并自动执行。这意味着您可以设置Vet在新的依赖项违反您的策略时使构建失败或提醒您的团队——有效地将CRA相关控制嵌入CI/CD。
- sbom
- EU
- CRA
- dependencies
SafeDep博客的最新动态
关注以获取开源安全与工程方面的最新更新和见解