《欧盟网络韧性法案》的报告时限自2026年9月11日起开始计算
了解哪些已达到生命周期终点的开源软件会给您带来风险，然后在倒计时开始之前，确保这些软件已安装补丁并符合合规要求。
适用于任何将产品投放到欧盟市场的公司——无论其总部设在哪里。
报告义务自
00
DAYS
00
营业时间
00
MIN
00
SEC
截止日期——2026年9月11日
在9·11事件之前，要清楚自己所立足之处。
涵盖四个领域的十六道题目，每道题都与相应的法律条文相关联。您可以查看自己的得分、各章节的薄弱环节，以及应优先改进的地方。查看结果无需注册。
16个问题
4 个部分
约4分钟
您的CRA准备情况报告
依据《欧盟法规》（EU）2024/2847。本工具仅提供一般性指导，不构成法律建议，亦非合规认证。
这份检查清单介绍了你的流程。现在来看看你的代码中实际包含什么内容。
上述问题旨在了解您是否建立了相关流程：包括政策、联络点以及支持期限承诺。这些问题无法告诉您，产品中的开源组件是否已于今日达到生命周期终止。这是一个截然不同且更为具体的问题，而这通常正是根据第14条需要上报的漏洞。
《网络韧性法案》的报告时限已开始计算，且以小时为单位，而非季度。
“含数字元素的产品”制造商必须通过新的CRA统一报告平台，报告正在被积极利用的漏洞和严重安全事件。一旦制造商发现某款产品存在正在被积极利用的漏洞（或发生严重安全事件），将启动一个分为三个阶段的计时流程：
预警
在……之内
24小时
通过ENISA单一报告平台向贵国的CSIRT提交初步通报（ENISA可同时查看该通报）
完整通知
在……之内
72小时
一份包含目前已知详情及已采取的任何纠正措施的完整通知。
最终报告——已利用的漏洞
在……之内
14天
在纠正措施实施后14天内提交最终报告。
最终报告——事件
在……之内
1个月
对于严重的安全事件，须在一个月内提交最终报告。
这不仅仅适用于新产品。
该报告义务适用于已进入欧盟市场的产品——包括遗留软件。“我们会在下个版本发布前处理”这种说法不适用。此事不容拖延。
报道为先，其余皆次之。
全部基本要求（安全设计、软件物料清单（SBOM）、CE标志）将于2027年12月11日起正式生效。报告要求作为近期推动措施，将于2026年9月实施。
处罚规定，简明扼要。
若未履行核心义务，可能面临最高1500万欧元或全球年营业额2.5%的罚款，以较高者为准。
快速参考
报告截止日期
2026年9月11日
适用于旧版产品吗？
是
仅限欧盟企业吗？
不
最高处罚
1500万欧元 / 营业额的2.5%
全部基本要求
2027年12月11日
您不必位于欧洲，也符合适用范围。
适用范围取决于市场存在情况，而非总部所在地。“这仅适用于欧盟公司”是人们对《CRA》最常见的误读，也是潜在代价最高的误读。如果您符合以下任一情况，则本规定适用于您：
您是向欧盟销售产品的软件供应商或独立软件供应商（ISV）
即使是间接的，甚至是通过渠道合作伙伴——无论你是否这样认为，根据该法案，你都属于“制造商”。
您拥有欧盟客户、一家子公司，或在欧盟销售单一SKU
只要有一款产品投放到欧盟市场就足够了。贵公司的总部所在地不会改变这一事实。
您是一位安全或合规负责人，目前正在处理软件物料清单（SBOM）和审计请求
现在，在您原本需要遵守的框架之上，又增加了一项严格的外部报告时限。
你知道技术栈中存在未获支持的开源组件——但无法完全查明其来源
你知道技术栈中存在未获支持的开源组件——但无法完全查明其来源
截止日期并不是最难的部分。
难的是弄清楚你该写些什么。
对于一个你根本不知道存在的组件中的漏洞，你不可能在24小时内完成报告，但审计人员却会对此抱有期待。已停止维护、不再受支持的开源软件，正是那些往往在为时已晚之前都难以被察觉的隐患。一旦某个框架不再获得官方更新，就没人会关注它了——除了HeroDevs。
EOL 不是 CVE
问题在于没有人对新漏洞进行修复。你的 CVE 扫描器并非设计来标记“今后将无人修复该组件中的新漏洞”这一情况。在已停用（EOL）软件的扫描结果中未显示任何 CVE，并不意味着这些漏洞不存在，而是说明你的扫描器未能全面掌握情况。
它隐藏在传递依赖中
最可能给你带来麻烦的已停用组件，往往是你没有直接选择的那些——也就是你所依赖组件的依赖项。
没有值得辩护的内容可报告
即使你及时发现了这个问题，上游也不会提供修复方案，因此你无法拿出任何能证明自己已尽善意努力的证据，而且时间已经来不及进行最后一刻的更新或迁移了。
如何在9月前做好准备
两个步骤：先弄清楚自己立足于何处，然后确保这一立足点稳固。
HeroDevs 同时解决了这两个问题——可见性问题和修复问题——因此您可以根据自己的时间安排（而非框架规定的时间）如实提交报告。
步骤 1 · 可见性
EOL Dataset 能告诉您哪些开源组件已经达到生命周期终止（EOL）且不再受支持——这是您的 CVE 扫描器无法检测到的风险。它与您现有的 SCA 工具协同工作，而非与其冲突：SCA 工具会显示已知的 CVE；而 EOL Dataset 则会指出那些已被遗忘的组件。
可查找被弃用、已停用以及即将停用的依赖项——包括大多数依赖项清单中容易遗漏的传递性依赖项。
四种清晰的状态，让您清楚了解哪些产品已不再提供支持，哪些即将停止支持。
一份可向合规部门提交且经得起推敲的库存清单——这是您进行报告时不可或缺的依据。
该平台依托于1900多万个开源软件包的生命周期数据，因此针对特定组件的答案早已存在，无需您的团队另行研究。
步骤 2 · 整改
Never-Ending Support (NES)
一旦您了解了哪些组件已达到生命周期终止（EOL），NES 就会持续为其提供补丁，包括框架正式终止支持后新发现的 CVE，因此您总能提交具有充分依据的报告。安全可靠的即插即用替代方案，完全按照您的时间表推进，即时解决问题，既不妥协，也不造成中断。
团队中拥有原始框架的维护者——AngularJS 、Spring 、Vue、Bootstrap 等。
CNA 状态——HeroDevs 能够主动发现并修复 CVE，而不仅仅是针对公开披露的信息做出反应。
涵盖所有严重程度的补丁，即装即用——不会对您的应用程序造成破坏性变更，可立即修复问题。
证明函——合规专员可向审计师出示的文件。
团队最常向我们提出的问题
当然，如果您找不到想要的答案，请随时联系我们。
NES究竟废除了哪些条款、强化了哪些条款，又保留了哪些条款。
请将此视为一种范围界定工具，而非合规声明。一个未受维护且已达到生命周期终点的组件，会因违反多项规定而导致严重不合格；而商业支持则能使这些违规项转为合格。对于其他规定，商业支持仅能起到强化作用；而对于某些规定，则完全不起作用。
NES 直接弥合了这一差距
在此情况下，已停产（EOL）组件属于硬性故障。NES将其判定为“通过”，因为供应商已恢复补丁的发布。
应立即处理并修复漏洞，包括提供安全更新。
最契合的选择——这正是NES所做的。
在声明的支持期内（至少五年），按照附件一第二部分的规定处理漏洞。
锚定条款。正是NES使您能够针对包含已停用组件的组件堆栈声明5年以上的支持周期。
该产品投放市场时，未发现可被利用的已知漏洞。
包含未打补丁的CVE的已停用（EOL）依赖项，在添加时即为已知可被利用的漏洞。NES提供了向后移植的修复程序。
安全漏洞可通过安全更新加以解决。
如果上游项目已停止维护，则完全没有更新途径。NES 会通过 npm、Maven 或 PyPI 恢复更新途径。
安全更新将及时、免费地发布，并附有安全公告。
没有维护者就意味着无法发布。NES 同时提供该软件包和安全公告。
一旦有更新可用，便会公开披露已修复的漏洞。
HeroDevs 的安全公告和漏洞目录条目为此组件提供了相关信息。
每项安全更新将至少提供10年的支持，或直至支持期结束。
你无法保留从未发布的更新。NES 负责生成构建产物；而保留与否则由你决定。
NES 巩固了这一地位，但义务仍由您承担
对第三方组件的尽职调查
为已达到生命周期末期（EOL）的依赖项获取商业支持，是一项可记录的尽职调查行为——这也是你所拥有的最具说服力的证据。
通知组件维护者
如果上游交易无法进行，就找不到交易对手。NES 能为您提供一个。
24小时、72小时和14天的报告
NES 并不会免除这一义务。它为你提供了一项可供参考的纠正措施，这使得最终报告能够切实完成，而非成为一项开放式的承认。
软件物料清单
NES 并不生成您的 SBOM——它只是更改了 SBOM 中显示的内容。
协调的漏洞披露
HeroDevs 针对该组件制定了相关政策；而产品层面的政策仍由贵方决定。
用户的支持期限信息
正是NES，才使得宣布的支持终止日期具有可信度。
NES 对这些毫无帮助，我们也不会对此装作若无其事。
产品分类（第6至8条）、实质性修改（第20条）、欧盟符合性声明（第22条）、符合性评估程序（第24条）、CE标志（第30条），以及适用于您自身第一方代码的第13条第1款。如果您在符合性评估方面进展滞后，NES并不能解决这一部分的问题。
简而言之：NES 将违反第 13(8) 条的情况转化为符合第 13(8) 条的情况，并将未采取补救措施的第 14 条报告转变为附有纠正措施的报告。对于其他情况，它仅提供支持，但不予以免责。
在9·11事件之前，要清楚自己所立足之处。
在报告期限开始之前，找出那些你尚未察觉的已停止维护的开源软件，并确保其余软件均已安装补丁且符合审计要求。