惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Engineering at Meta
Engineering at Meta
Cloudbric
Cloudbric
云风的 BLOG
云风的 BLOG
A
About on SuperTechFans
The GitHub Blog
The GitHub Blog
IT之家
IT之家
F
Full Disclosure
B
Blog RSS Feed
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Hugging Face - Blog
Hugging Face - Blog
B
Blog
H
Help Net Security
The Cloudflare Blog
Recorded Future
Recorded Future
P
Proofpoint News Feed
P
Proofpoint News Feed
C
Cisco Blogs
T
Tailwind CSS Blog
P
Palo Alto Networks Blog
D
Docker
爱范儿
爱范儿
Know Your Adversary
Know Your Adversary
博客园 - 聂微东
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Y
Y Combinator Blog
雷峰网
雷峰网
AWS News Blog
AWS News Blog
D
DataBreaches.Net
博客园 - 司徒正美
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
博客园 - Franky
C
Cybersecurity and Infrastructure Security Agency CISA
Blog — PlanetScale
Blog — PlanetScale
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Latest news
Latest news
Google DeepMind News
Google DeepMind News
Martin Fowler
Martin Fowler
MongoDB | Blog
MongoDB | Blog
C
CERT Recently Published Vulnerability Notes
阮一峰的网络日志
阮一峰的网络日志
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
C
CXSECURITY Database RSS Feed - CXSecurity.com
酷 壳 – CoolShell
酷 壳 – CoolShell
C
Cyber Attacks, Cyber Crime and Cyber Security
腾讯CDC
小众软件
小众软件
G
Google Developers Blog
Hacker News - Newest:
Hacker News - Newest: "LLM"
Scott Helme
Scott Helme
O
OpenAI News

博客园 - Trinitytec

什么是CWE?概述CWE排名前25项 为什么Rust嵌入式开发仍然需要强大的静态分析 面向产品安全的威胁建模与Secure SDLC实践 让Google Test满足功能安全要求:VectorCAST/QA构建可量化的测试覆盖率分析体系 FOSSID如何快速且准确找到项目中引用的第三方代码 如何利用FOSSID 管控AI生成代码合规性? CRA生效在即,ONEKEY携手创提将网络安全合规压力化为市场红利 借助 Rust + Perforce 静态分析工具QAC和Klocwork降低关键风险 eVTOL核心机载软件系统满足DO-178C适航合规的工程实践 云端自动化测试--通过基于服务器的自动化测试实现SDV创新 开发人员需要了解的关于MISRA C:2025®的信息 AI辅助代码修复优化左移开发 在AWS上部署CANoe--打造企业级ECU云端流水线 AI生成代码系列:在不干扰开发者体验的情况下集成开源代码片段检测 CVE资金中断:安全团队如何做好准备? AI生成代码系列:开源代码片段检测的有效方法 将Perforce QAC与CI/CD流水线集成实现代码“质量门控”管理 CVE是什么?常见漏洞披露概述 如何生成完整的软件物料清单(SBOM)? 如何选择一个好的软件成分分析工具? Perforce公司发布《2025汽车软件开发报告》 重新审视中国的GB标准(44495 – 44497) 硬件逆向工程101: 电路板基础知识 HydraLink—面向工程师、研究人员和爱好者的易用型汽车以太网接口 车载网络:现代汽车的数字心跳 最具影响力的汽车黑客攻击事件 网络安全全速前进:McLaren迈凯伦汽车如何应用Cybellum驱动卓越的产品安全? 浅谈TARA在汽车网络安全中的关键角色
为何应立即实施 SBOM,以满足《网络弹性法案》(CRA)的合规要求
Trinitytec · 2026-07-16 · via 博客园 - Trinitytec

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 年的丰富经验。