为什么你的已停用（EOL）开源技术栈是合规风险，而非技术债务
欢迎与注意事项
艾琳·汉纳福德：大家好，欢迎参加我们的网络研讨会——《为何您即将淘汰的开源技术栈不仅是技术债务，更是合规风险》。我是艾琳·汉纳福德，今天将由我主持本次网络研讨会。
在正式开始之前，我想先说明几点注意事项。今天的网络研讨会将进行录制，会议结束后，我们会通过电子邮件向大家发送录像和配套的白皮书——请留意您的收件箱。
我们在最后预留了充足的时间用于答疑。在网络研讨会进行期间，欢迎随时使用评论功能提出问题或发表意见，我们将尽可能在直播中回答尽可能多的问题。对于无法在直播中解答的问题，我们将在网络研讨会结束后直接与您联系跟进。
现在，请允许我介绍今天的演讲嘉宾——HeroDevs首席运营官罗布·纳伦。罗布，请开始吧。
罗布·纳伦：谢谢，艾琳。很高兴见到大家——我非常期待讨论这个话题。
先介绍一下背景：正如大家所知，我是HeroDevs的首席运营官（COO）。我们的目标是帮助企业满足其内部和外部的合规要求，包括欧盟《云服务提供商条例》（CRA），我们稍后将就此展开讨论。 为此，我们提供持续的CVE修复服务，并为生命周期结束的开源软件提供支持。作为向企业提供这些服务的一部分，我们与OpenJS基金会、Linux基金会和Commonest基金会等开源社区建立了战略合作伙伴关系，同时也直接与Bootstrap 、Vue、.NET 等众多开源项目展开合作。
本次网络研讨会的目标，不仅在于详细介绍欧盟CRA（开放源代码责任法案）的具体内容以及企业如何确保合规，还将阐述该要求出台的背景，并探讨随着人工智能和开源技术的发展，全球范围内即将推出的其他相关要求。 我们将探讨组织在面对已停止维护的开源软件时，应如何思考合规问题。最后，我们将进行问答环节，我期待能与大家深入探讨相关问题和话题——进行一些互动讨论总是很有趣的。
历史总在重演：从个人数据中汲取的教训
基于这一点，让我们快速回顾一下历史是如何重演的，以及我们如何从中汲取经验，为未来发展提供借鉴。
在讨论《网络韧性法案》之前，我想先放眼全局，因为这一切并非完全新鲜事。我们目前在软件和人工智能领域所经历的，其发展轨迹与我们此前在个人数据的收集和使用方面所见的情况如出一辙。
那么，我们先从这一模式说起。大约十五年前，企业意识到它们可以以一种前所未有的规模利用个人数据。这种价值对企业而言伴随着风险，而这种风险主要落在了那些从未真正同意过其数据被利用或使用的人身上。在最初的几年里，个人数据保护的模式只是“尽最大努力”，背后缺乏明确的问责机制，更没有明确的立法或合规标准来规范行为。
简而言之，安全事故接二连三地发生，大量用户的个人数据遭到泄露，最终促使相关法律随之出台。在欧洲，是《通用数据保护条例》（GDPR）；在美国，则是《格雷姆-里奇-比利利法案》（Gramm-Leach-Bliley Act）、《健康保险流通与责任法案》（HIPAA），以及后来的《加州消费者隐私法案》（CCPA）。
对于从事合规工作的人士来说，想必还记得这些标准的推行过程并不顺利。有些人可能还记得“施雷姆斯一案”的裁决，不过对此或许并不太怀好感。2015年，欧洲法院一夜之间推翻了美欧“安全港”框架，裁定该框架未能充分保护欧洲人的数据。 成千上万原本自认为符合合规要求的企业，突然发现自己不再合规。正是这一案件，连同其他几起类似案件及相关事态发展，共同推动了《通用数据保护条例》（GDPR）的出台。“尽最大努力”的保护措施由此转变为一项强制性、持续性且可强制执行的义务——一旦违反，将面临实际处罚。
我们现在看到的是，个人数据正被用于支持人工智能和开源技术，而同样的局面再次上演。企业正大规模采用开源技术，而人工智能则进一步加快了开源软件的交付速度。风险通过代码蔓延，波及到所有依赖它的人。这些因素对基础设施和应用程序的安全性产生了显著影响，从而引发了大量安全事件——其中一些我们稍后将进行讨论。
关键在于，各国的应对措施在形式上如出一辙：正在制定相关立法和合规标准，以确保安全不再只是“尽最大努力”的可能，而是必须有据可依并得到充分支持。这些立法包括欧盟的《云服务提供商法案》（CRA）、《网络和信息系统安全指令2》（NIS2）以及《数据可信度法案》（DORA）等，而在美国，也有数不胜数的相关要求。
开源与人工智能驱动的风险规模
为了帮助大家了解开源技术的采用情况以及人工智能带来的变化，Black Duck、Sonatype 以及业内其他公司提供了一些有参考价值的数据。
就开源而言，我认为其普及程度已毋庸置疑——企业，乃至整个世界和互联网，都完全依赖于开源。具体来说：
- 每年约有10万亿次开源软件下载请求。
- 仅在 GitHub 上，开发者人数就超过1.5 亿。
- 目前，70%的代码都是开源的。
- 每个企业级应用程序平均包含900多个开源依赖项。
对于那些不熟悉开发者组织的人来说，这可能令人惊讶，但这不仅仅是因为使用量巨大——更因为企业所依赖的主要组件是由开源社区创建和分发的。鉴于开源软件的广泛应用，保持系统处于最新版本几乎是不可能的，尤其是考虑到产品生命周期要求，这可能需要企业为其客户保留某些版本。我们稍后会详细讨论这一点。
关于人工智能：大家都知道，相关更新似乎每天、每周都在发布。就我个人而言，几乎每天都会听到一些我原本认为人工智能无法做到或不会去做的事情。关于人工智能未来能做什么、会做什么，目前仍有许多悬而未决的问题——但我们确实知道它现在擅长什么，而眼下，人工智能在发现漏洞方面表现得极为出色。这正导致CVEs数量激增。
HeroDevs 已经观察到了一些非常明显的例子。以Spring Framework 为例：2025 年，Spring Framework 共披露了17 个CVE。截至本次网络研讨会举办之日，2026 年的披露数量已超过200 个。
这不仅影响企业，也影响那些必须审查这些新报告的安全问题的社区和项目。他们现在每周都要处理数千份请求，必须对这些请求进行审查，以便在漏洞被利用之前发现并修复它们。像Anthropic的Glasswing计划这样的项目已迅速提高了CVE的识别率，而包含恶意代码的开源软件包数量也在不断增加。
这两个因素——开源软件的使用规模以及漏洞发现速度的加快——对企业的影响最为显著，因为企业使用的开源软件数量庞大，而要跟上这些产品的生命周期，对它们来说确实非常、非常困难。一旦落后，企业就无法再依赖上游补丁和CVE修复程序，因为社区已经不再提供这些更新。
推动监管的违规事件时间线
我将简要回顾一下个人数据监管的历史，但不会深入探讨，因为在座的许多人可能对此仍有心有余悸。如果回顾时间线，我们会发现当前的合规标准大多源于一些重大事件。对我而言，了解这些要求的历史背景有两个好处：首先，当我弄清楚问题根源时，处理起来会更轻松；其次，这有助于我们预判未来的发展趋势。
回顾斯诺登的爆料事件和TalkTalk数据泄露事件，你会发现，《通用数据保护条例》（GDPR）的出台和执行紧随几起规模巨大的个人数据泄露和披露事件之后。
回顾欧盟《网络安全法案》（CRA），我们可以看到类似的趋势。以2017年Equifax数据泄露事件为例，该事件导致数百万人的个人数据泄露，Equifax因此被美国联邦贸易委员会（FTC）处以超过5亿美元的罚款。此外，还有Log4Shell事件，我们稍后会详细讨论。其发展脉络如出一辙：重大安全事件发生后，相关标准便随之提高。
这里需要特别注意的是——无论从个人数据的角度，还是从较新的基础设施安全角度来看——使用已达到生命周期末期的开源软件都会直接影响这两方面，无论是根据《通用数据保护条例》（GDPR）第32条，还是根据《欧盟云服务责任条例》（EU CRA）第13(8)条。
这不仅仅是一个欧洲的故事——而是全球性的。加拿大有《C-26法案》。美国则有一系列新近发布的行政命令、FedRAMP、CMMC 2.0和PCI要求，此外还有针对《健康保险流通与责任法案》（HIPAA）的修订提案和安全全面改革。在全球范围内，类似的要求正日益增多，包括亚太地区（APAC），例如澳大利亚就颁布了《网络安全法》以及CPS-A标准。
这些要求不仅将影响相关组织，还将影响向受影响公司提供软件和服务的供应商。从宏观层面来看，这些合规标准都包含相同的核心要素：
- 清楚自己正在运行和使用什么。
- 制定相关流程，并具备修复漏洞的能力。
- 制定相关流程，并具备报告可能影响个人信息或一般信息的严重事件的能力。
- 备妥可供审计的文件，以便向任何管理机构出示。
介绍《欧盟网络韧性法》（CRA）
既然我们已经回顾了相关历史，接下来就具体谈谈欧盟《消费者信贷条例》（CRA）——其中部分内容已经生效，并将产生广泛的影响。
首先，让我们明确欧盟《网络安全法》（CRA）的本质：这是首部“横向”网络安全法。“横向”意味着这是首部适用于所有产品类别、而不仅限于某个特定行业的立法。 作为对比，大家可能都熟悉《数字运营韧性法案》（DORA），该法案于2025年1月生效——但它专门适用于金融机构以及向其提供特定服务的组织，因此属于行业特定或垂直领域的法规。
《欧盟产品生命周期管理条例》（CRA）由欧盟委员会提出，并经欧洲议会和欧盟理事会通过。其正式名称为《（欧盟）CRA条例》——虽然没人会用这个全称，但还是告诉大家一下。该条例的主要目的是对任何含有数字元素的产品设定强制性的生命周期管理义务。
欧盟CRA的四大支柱
强制性生命周期义务围绕以下四个主要要素构建：
- “安全设计”。提供或使用包含数字元素的软件产品的企业，必须将网络安全功能直接嵌入软件中——而不是事后作为附加功能来添加。这些功能必须在整个支持周期内得到维护。
- 漏洞处理。这是一项持续的义务，旨在根据需要识别、记录、修复并报告安全漏洞。这包括及时、安全地分发补丁，以及制定协调漏洞披露（CVD）政策，以便安全研究人员和客户能够报告问题。
- 事件报告。若发现漏洞，必须制定明确的文档和流程，以确保在规定时限内进行通报。
- SBOM 要求。软件物料清单（SBOM）——一份可机读的清单，列出了数字产品中所有软件组件、库和依赖项。
这些是欧盟信用评级机构（CRA）框架中的四个基本要素。
什么算作“数字元素”？
欧盟《CRA》适用于含有“数字元素”的产品——这一术语的涵义正如字面所示，范围非常广泛。数字元素可包括操作系统、桌面和移动应用程序、固件以及库文件。其中也包含嵌入式开源软件。简而言之，凡是将设备连接到网络或使设备相互连接的任何内容均属此列。
还有一些例外情况由其他监管要求来处理——例如，纯SaaS服务受《网络和信息系统安全指令2》（NIS2）管辖，而汽车、航空和医疗等特定行业则受各自的标准约束。尽管如此，“数字要素”的定义还是被有意设定得非常宽泛。
有一项例外情况值得澄清，即非商业性开源软件。非商业性开源软件是指完全免费开发和提供的软件，不采用任何商业模式，也没有实现盈利的途径——即无意通过分发该软件获利。实际上，这一豁免主要适用于上游项目和社区。需要明确的是：任何将开源软件（包括非商业性开源软件）捆绑到其产品中的制造商，均须遵守《欧盟计算资源法案》（CRA）。
与《通用数据保护条例》（GDPR）一样，《欧盟消费者权益保护法》（CRA）也具有域外效力。如果您虽不在欧盟境内，但向欧盟销售产品，那么无论您在何处注册成立或开展业务，该法规都适用于您。
Log4Shell事件的来龙去脉
值得注意的是，欧盟委员会关于《欧盟网络安全法案》（EU CRA）的提案中特别提到了Log4Shell漏洞。一个名为Apache Log4j的小型Java库被嵌入到数百万个应用程序中。一夜之间，一个安全漏洞使互联网的大部分系统面临风险：该CVE漏洞允许攻击者从互联网上的任何位置在目标计算机或服务器上运行恶意代码。利用该漏洞者可能获得完全控制权、窃取数据、安装勒索软件，或发起全面网络攻击。
这揭示了一个欧洲委员会正试图解决的严峻现实：在所有这些部署中，没有人对Log4j的安全性负责。欧盟《消费品安全条例》（CRA）将这一责任归于将产品投放市场的一方。
欧盟信用评级机构（CRA）的重要截止日期和相关条款
让我们快速回顾一下时间线，并更详细地探讨欧盟《信用评级机构条例》（CRA）的一些关键要素。
- 欧盟信用评级机构法案（CRA）是由欧盟委员会于2022年提出的。
- 该法案于2024年12月生效，自那时起，人们才开始更加关注它。
- 2026年9月11日——漏洞报告义务现已生效。（截至本次网络研讨会举办时，这已是上周的事了。）
- 2027年12月11日——全部要求正式生效。
因此，从今天起，漏洞报告时限实际上已经开始计算。如果贵产品的某个漏洞正在被积极利用，您必须通过欧盟网络安全局（ENISA）的“统一报告平台”（SRP）进行报告。该报告将由国家计算机安全事件响应小组（CSIRT）接收并审核。 若想进入欧盟CRA体系，您必须熟悉这些首字母缩写词——这是必不可少的。
时钟很急躁：
- 24小时——预警要求
- 72小时——全面通知
- 14天——在修复程序发布后提交最终报告
重要的是：如果您在9月之前已发货，且产品已投入使用，那么您目前仍需履行这些义务。欧盟《可追溯性条例》（CRA）对适用范围的广泛定义并不局限于某个特定行业，也不仅限于主要在欧盟开展业务的组织——只要您在欧盟开展业务，该条例就极有可能对您产生影响。
当前最重要的三项要求
第13条第8款——支持期限。提供含数字元素产品的制造商必须声明至少五年的支持期限。在这五年内，他们必须处理每个组件（包括嵌入式开源组件）中的漏洞。 更新还必须持续提供十年——此举旨在防止制造商利用许可条款在事后撤回修复程序。监管机构希望给依赖该软件的用户留出迁移时间，因此制造商不得在发布修复程序后立即将其撤回。
第14条——漏洞报告。本条涉及上文所述的24小时/72小时/14天的报告时限。企业当前应采取的关键措施：
- 如果您提供的产品包含数字元素，请指定一名负责人——即在发现漏洞时负责登录 ENISA SRP 系统的人员。
- 请该代表提前创建一个欧盟登录账号（即欧洲委员会的账户）——但请注意，欧洲委员会明确建议不要直接在SRP平台上进行预注册。
- 制定明确的内部流程，规定在SRP报告期间各方的职责分工。
附件一——SBOM要求，自12月起实施。主要包括四个方面：
- 为软件产品的每个不同版本生成可机读的软件物料清单（SBOM），将其作为技术文档的一部分包含在内，以便监管机构（监督部门）进行审查。
- 持续更新 SBOM——它不能是十二个月前的过时快照；它必须反映当前的组件、补丁和更新。
- 整合漏洞处理功能——SBOM 应与持续漏洞匹配和跟踪工具集成，以支持合规性并实现快速报告。
处罚
目标是让每个组织都满足这些要求并保持合规——但欧盟《消费品安全法规》（CRA）背后确实具有强有力的强制执行力。处罚金额最高可达数千万欧元，或全球年营业额的一定比例，以较高者为准。对于严重违规行为，相关产品可能会被完全撤出欧盟市场，这可能会带来严重后果。
现在该怎么办
- 了解您在欧盟《数字服务法》（CRA）中的适用范围——请仔细阅读相关定义。如果您向欧盟提供数字内容，则受该法规影响。
- 请确认您的指定代表。
- 开始评估能够协助生成机器可读的SBOM的供应商。
- 部署一个 DevSecOps 平台，以便实时监控风险。
- 与您的指定代表一起，演练24小时/72小时/14天的报告工作流程。
- 保留证据——审计轨迹、DevSecOps 记录和软件物料清单（SBOM）将至关重要。
2027年12月看似遥远，但转眼即至——而对于那些依赖已达到生命周期末期的开源软件的组织而言，届时将受到最沉重的打击。
“生命周期结束的开源软件”究竟意味着什么
我们已经介绍了《反洗钱法》（CRA）的背景、制定依据及其具体要求。现在，让我们重点探讨当今组织面临的最大风险所在。
“生命周期结束的开源软件”可能有以下几种含义：
- 已被社区彻底抛弃。示例：AngularJS 。Google 已不再维护该库，因此用户不得不迁移到 React 或现代版的Angular 。如果你仍在使用AngularJS ，请注意：社区既不会对其进行安全漏洞审查，也不会提供 CVE 修复程序。
- 即使项目本身仍在活跃开发，但某个版本已不再获得社区支持。例如：Spring 框架，用于构建企业级Java应用程序。该社区有固定的发布周期，旧版本将不再获得CVE修复——因此，如果您正在使用Spring Boot 2.5，该版本已达到生命周期终止，即使由于人工智能的影响，安全问题呈指数级增长，社区也不会为此提供修复程序。
人们很容易认为，组织不会依赖存在已知严重或高危CVE且已停止维护的软件，但事实是：
- 目前，企业组件中已有5%至15%已达到使用寿命终点。
- 有超过81,000个软件包存在已知的 CVE 漏洞，且尚无已知的修复方案，因为开发社区已经转向其他项目。
- 这种风险不仅限于大家首先想到的主要依赖项或框架——实际上，93%的这些 CVE 存在于许多组织从未明确选择的传递性依赖项中。它们只是部署的解决方案中固有的组成部分。
这一问题并未缓解。仅在4月至7月期间，MySQL、Node.js、Django 、Angular 以及Spring Boot就相继迎来了重大生命周期终止事件——所有这些都发生在90天内。使用这些工具的企业不得不全力以赴推进现代化改造并保持在受支持的版本上，这往往是以牺牲其他项目和价值创造工作为代价的。
真实的合规风险案例
这并非一个假设性问题。目前有两个实例与欧盟《反洗钱法》（CRA）直接相关：
- Spring 该安全漏洞存在一个关键的 CVE，会悄无声息地阻止 HTTP 安全标头的应用。应用程序仍会继续运行并通过所有状态检查，但至关重要的浏览器端防护却完全消失，且不会记录任何错误或警告。
- Angular 存在一个高危CVE漏洞：一个跨站脚本漏洞，该漏洞允许攻击者在用户的网页上运行有害的JavaScript代码，并将恶意代码隐藏在Angular 应用程序中的翻译文本文件内。
在这两种情况下，根据欧盟《网络安全法》（CRA）——甚至《数据保护法》（DORA）——相关组织可能会面临两种潜在的违规情况：首先，因在包含数字元素的产品中运行不受支持的软件版本，而违反第13条第8款；其次，如果该组织未能在第14条规定的报告期限内进行报告。
已达到生命周期的开源软件使用现象十分普遍，这种使用可能导致不符合欧盟《云服务提供商责任条例》（CRA）、《通用数据保护条例》（GDPR）及其他标准的要求。
两条前进之路
那么，对此该怎么办呢？有两种选择。
方案 1：迁移到受支持的版本。这听起来很直观，但正如这里许多技术人员所证实的，迁移过程可能极其困难——尤其是涉及生态系统中的依赖关系时。 例如，迁移Spring 可能还需要放弃Java 8，这会使您的迁移时间表延长至十二个月以上。在此期间，您投入资源进行现代化改造却未能获得多少新功能——更糟糕的是，在此期间您仍处于不符合规范的状态。这条路径要求企业对部署的开源软件进行极其周密的考量，并时刻关注产品生命周期终止事件，而鉴于开源软件的广泛采用，做到这一点非常困难。
方案 2：寻找能够为已停用的软件提供支持的供应商。这正是 HeroDevs 的用武之地——我们为已停用的开源软件提供可直接替换的替代方案。作为我们订阅服务的一部分，您将在整个服务周期内获得 CVE 漏洞修复和支持，这使企业能够在保持合规的同时，自主掌控现代化转型的时间表。
环境修复市场的繁荣——以及如何甄别供应商
随着围绕人工智能的讨论日益热烈以及CVE数量的激增，目前正出现一种我亲切地称之为“修复市场繁荣”的现象。SCA工具及类似解决方案在识别已终止维护的开源软件中的CVE方面已相当成熟。但现在真正的关键问题是：一旦发现CVE，该如何应对？
2025年披露的CVE数量达到48,000个——同比增幅超过250%——各厂商正大力宣传称，他们能够修复开源软件中的漏洞，包括那些已不再获得社区支持的版本。 我亲眼目睹过一些组织声称仅靠人工智能就能做到这一点。但包括1Password在内的最新研究发现，在完全由人工智能生成的补丁中，实际上只有四分之一真正修复了底层漏洞或CVE。
就我们而言，HeroDevs 进行了一些调研，发现一家知名供应商宣称已修复了Spring 上的 CVE 漏洞。当我们查阅相关文档时发现，在这家供应商声称已修复的 258 个Spring CVE 漏洞中，近三分之二的漏洞实际上并没有有效的修复方案。
鉴于此，我强烈建议任何在评估供应商的人都要获取切实的证据，而不是仅凭供应商（包括我们）的一面之词就轻信对方。具体来说：
- 请索取将特定 CVE 与特定版本关联起来的发布说明。
- 请求提供突出显示已修复 CVE 的VEX 语句。
- 检查供应商的专业能力。仅靠人工智能并非万能良方——应选择已注册为CNA（认证漏洞分析师）且拥有实际发现CVE（通用漏洞披露）的业绩记录的供应商，而非仅依赖上游补丁。
- 执行一次概念验证扫描。确认该修复措施不会导致应用程序出现故障，并且——这一点非常重要——确认它并非仅仅通过版本号提升来消除负面检测结果，而实际上底层的 CVE 漏洞仍然存在。
缺乏适当的支持不仅对您构成风险——它还会影响您遵守这些法规的能力，进而给您的客户带来风险。
总结要点
历史总是重演，我们以前就见过这种趋势。欧盟CRA绝不会是此类要求的最后一个——请利用为符合欧盟CRA要求而建立的实践，为接下来的挑战做好准备。开源软件的采用率已飙升至历史新高，而人工智能则使发现漏洞变得更加轻松快捷。正因如此，制定一项计划来支持已达到生命周期终点的开源软件并满足欧盟CRA要求至关重要。
欧盟信用评级机构（CRA）的监管要求已经开始实施——这并非“12月才全面生效”的事。实际要求已经生效。因此：
- 请确认您的指定代表。
- 设置您的欧盟登录账号。
- 请确保您能够访问 SBOM，并正在扫描漏洞，以便能够按时提交报告。
- 请认识到，已达到生命周期终点的开源软件是一个必须解决的直接合规问题——应选择具备相关专业知识和经验的供应商来提供帮助。
问答
艾琳·汉纳福德：非常感谢，罗布。我们收到了一些提问，我就从第一个开始吧。
参会者提问：您刚才简单提到了机器可读的SBOM。能否详细说明一下，机器可读的SBOM能提供哪些代码仓库依赖清单中尚未包含的功能？
罗布·纳伦：问得好。你的 package.json 或 pom.xml 文件会告诉你开发人员直接选择添加了哪些内容。 但是——这也正是欧盟CRA《附件I》所规定的义务所在——它既没有提供完整的依赖项列表，也没有提供评估人员希望看到的审计追踪记录。该审计追踪记录必须包含那些传递性组件，而这些组件极有可能并非由贵团队中的任何人明确选定的——这正是我之前提到的93%这一数字的来源。
这就是为什么软件物料清单（SBOM）如此重要。像CycloneDX或SPDX这样的格式设计上便于机器解析，并且能对比不同版本之间的差异。因此，当下一个类似Log4Shell的漏洞出现时，您可以更快地判断自身是否受到影响。理想情况下，您能获得全面的视图，而非局限于片面信息。
艾琳·汉纳福德：太好了，谢谢。拉尔夫想知道，我们如何验证供应商的修复方案是否真正解决了问题，而不是仅仅掩盖了问题——他看到过很多标记为“已解决”的工单，其实只是将问题转移到了扫描器无法检测到的地方。
罗布·纳伦：问得好。我想再提一下我之前提到的那四个问题。首先，在确定合作之前，要与供应商沟通，了解他们实际能提供什么——这可以是一个针对单一框架甚至单一修复方案的简单概念验证。
获取发布说明——其中应明确将特定的 CVE 与特定的版本关联起来。不能仅仅依赖那些只标注“是的，我们支持该漏洞”的营销页面。接下来，或许是最重要的一点，就是 VEX 声明——这些声明是机器可读的，您可以将其上传到 SCA 或 DevSecOps 平台，以核对它们是否与您自身的漏洞追踪记录相符。
除此之外，还要深入了解供应商本身：他们是否是经MITRE注册的CNA？对于HeroDevs修复的CVE，我们被明确标识为发现并修复该CVE的组织——这意味着我们并非仅仅依赖上游补丁的发布，而是主动出击，自行寻找这些问题。
最后，在进行概念验证时，请运行实际代码并确认这不仅仅是版本号的更新——这再次与VEX声明相关，也关系到该CVE是否真正得到了修复。采取这些措施将有助于您判断供应商是否具备所需的专业能力。
艾琳·汉纳福德：很好，我想我们还有时间回答最后一个问题。理查德问：如果我们已经制定了淘汰旧框架的多年计划，那根据《CRA》，我们是否就不受其约束了？
罗布·纳伦：问得好——遗憾的是，答案是否定的。根据其他一些法规，你可以以“处于开发阶段”为由申请豁免，从而降低风险。但在欧盟《化学品注册、评估、授权和限制条例》（CRA）下，这并不能免除贵组织遵守该条例的义务。 第14条规定的报告义务自2026年9月11日起正式生效，且适用于市场上所有产品——因此，仅凭正在推进现代化改造这一事实本身并不足以豁免合规义务。
我的建议是：各组织应立即通过其SCA扫描工具进行排查，找出已达到生命周期终止的开源软件所在位置，在可行的情况下尽快迁移至最新版本；若无法自行完成迁移，则应从今天起与HeroDevs等供应商合作，以获得所需的支持并确保合规。
艾琳·汉纳福德：谢谢你，罗布，也感谢各位的参与。今天的网络研讨会到此结束。请留意网络研讨会的录像及配套白皮书。谢谢。
