联系电话:
021-68580866
-
博客
希望我们能与您分享和探讨成长中的点点滴滴
为何应立即实施 SBOM，以满足《网络弹性法案》（CRA）的合规要求
创提信息
2026/07/15
分享到
CRA重要截止日期：
2026年9月11日，必须报告正在被利用的漏洞和严重安全事件。
2027年12月11日，全面落实关键网络安全要求，包括应要求提供软件物料清单（SBOM）。
乍一看，许多组织将2027年视为SBOM的真正截止日期，但这种理解存在风险。
实际上，如果没有完整、可靠且可按需获取的软件物料清单（SBOM），在操作层面根本无法履行2026年的报告义务。尽管该法规可能会分阶段实施，但必须立即建立相关能力基础。
没有资产清单，漏洞管理便无从谈起
漏洞管理的先决条件是可见性。看不见的漏洞，便无法管理。现代软件产品通常包含：
现代软件通常包含以下组成部分
● 开源库
● 传递性依赖项
● 商业 SDK
● 容器镜像
● 嵌入式组件
如果没有软件物料清单（SBOM），您将无法
● 识别新出现的通用漏洞披露与编号（CVE）
● 评估漏洞的可利用性
● 确定受影响的版本
● 在24小时内通知监管机构
在监管时间压力下手动重建依赖关系树是不切实际的，而且在法律上也存在风险。当一个正在被积极利用的漏洞被公开披露时，监管机构不会接受“不确定”作为答复。此外，仅依赖应用程序的包清单文件，无法看清未受管理的代码、复制粘贴的代码片段，以及可能复制第三方和开源组件的AI生成的代码片段的来源。
唯一可靠的做法，就是对产品内部情况有可追溯的了解。
24小时报告义务改变了风险模型
从历史上看，组织通常先进行调查，再进行报告。CRA 颠覆了这种惯例。一旦发现存在被积极利用的漏洞，制造商必须立即报告。这要求：
● 即时组件查询
● 跨版本的版本追溯
● 历史构建产物的保留
● SBOM 数据与漏洞情报源之间的自动关联
这些能力并非一蹴而就。那些等到2027年才开始“启用SBOM”的企业会发现，漏洞报告流程需要数月的运营磨合期才能稳定运行。
2026年的义务不仅仅是一个法律里程碑。它更是一个系统工程里程碑——即建立起自动化生成和管理软件物料清单（SBOM）的能力。
符合性评估需要证据，而非叙述
到2027年12月，带有数字元素的产品（PDEs）必须证明符合CRA的基本网络安全要求。
符合性评估将要求提供以下方面的客观证据：
● 生命周期漏洞管理
● 安全设计开发流程
● 持续依赖项监控
● 发布时不存在已知的可利用漏洞
SBOM 系统能够提供结构化且符合监管要求的证据。如果没有这一基础，组织就可能面临仅能提供政策声明而非实际证据的风险。这两者之间有着天壤之别。
延迟采用造成运营冲击
SBOM 的实施不仅仅是一个工具选择问题。它需要：
● 流程优化与重构
● 与开发人员工作流及 CI/CD 管道的集成
● 构建产物和发布管理的更新
● 工程、安全和法务团队之间的协作
推迟这项工作将增加以下风险：
● 2026年需进行紧急改造
● 2027年审计未通过
● 欧盟市场准入受阻
运营冲击是可以避免的。但前提是企业必须将软件物料清单（SBOM）视为基础设施，而非单纯的文书工作。
战略优势，而非合规负担
尽早采用 SBOM 可带来可量化的运营价值：
● 缩短漏洞影响评估的平均时间
● 提高软件供应链透明度
● 更好地为美国、英国、亚洲及其他地区的平行市场做好准备
最有韧性的制造商不会把 SBOM 当作监管负担，他们会把它当作产品基础信息（资产）。
需要明确的是
虽然《网络弹性法案》（CRA）并未规定必须在2026年9月11日前建立软件物料清单（SBOM），但鉴于该法案对漏洞管理、报告和合规性的要求，若无SBOM，合规将难以实现。
2026年的报告要求取决于SBOM的成熟度。
2027年的文档要求则将其正式化。
现在就开始实施的机构，将能够从容应对CRA的要求。
将 SBOM 战略付诸行动
如果CRA的时间表已经明确，那么接下来的问题就是如何着手：我们该从哪里开始？
1、注重准确性和完整性
构建 SBOM 终究是监管机构所期待的，它是特定版本中所有已编译并发布的组件清单。然而，如果辅以源代码 SBOM（即开发过程中代码库中现有内容的清晰视图），则能够更轻松地持续生成可靠的构建 SBOM。源代码 SBOM 有助于团队在发布前检测未申报的组件、经过修改的开源组件以及 AI 生成的代码片段。它并非取代最终的构建 SBOM，而是增强了其完整性。
2、在 CI/CD 生命周期内实现 SBOM 生成的自动化
构建 SBOM 应在构建时生成，与发布工件一同进行版本管理，长期保存，并持续与漏洞情报源进行关联。在 24 小时内必须提交报告的要求下，手动重建既无法实现规模化，也难以站得住脚。
将第三方 SBOM 视为输入数据，而非保证依据，您仍需对投放欧盟市场的产品承担责任。应验证、规范化并整合供应商提供的 SBOM，将其整合为统一的产品级视图，以便您在收到请求时能够按需提供。
3、明确考虑 AI 辅助开发
生成的代码可能会引入绕过传统声明的受许可代码片段或依赖项。您的扫描和治理流程必须扩展至 AI 生成的输出，以确保源代码 SBOM 和构建 SBOM 均能真实反映实际情况。
CRA 准备工作旨在立即构建可操作的 SBOM 情报，从而确保 2026 年的漏洞报告和 2027 年的合规性验证具有可预测性、可重复性和可审计、可证明。
作者简介
Aaron Branson
首席营销官（Chief Marketing Officer）
作为 FossID 首席营销官，Aaron Branson 负责公司技术产品和专业服务价值的市场传播，同时持续关注软件供应链安全领域的发展趋势以及客户面临的实际挑战，并通过分享行业洞察和实践经验，帮助企业更好地应对产品安全与开源软件合规方面的挑战。
Aaron 在软件设计、软件开发和项目管理领域拥有超过 25 年的丰富经验。