新的漏洞格局

执行摘要

本书探讨了软件漏洞的新现状，以及任何运行开源软件的组织应了解的内容，并得出了三点结论。

‍

首先，人工智能已从根本上改变了漏洞发现的经济规律。前沿人工智能模型如今能够分析代码库并推测出潜在的突破点。漏洞发现的速度正加速至机器级，而每一个已发布的修复方案都将成为开发利用漏洞的起点。

‍

其次，这种加速趋势对已停止维护（EOL）的开源软件造成的危害最为严重。当某个框架、运行时或库不再获得安全修复时，从当天起披露的针对该软件的所有漏洞都将永久无法修复，本电子书将此类风险称为“永恒漏洞”。 雪上加霜的是，大多数漏洞扫描工具无法察觉这一风险，因为它们仅追踪已知的 CVE，而非生命周期状态，而且大多数开源软件包从未正式宣布过生命周期终止。

‍

第三，该风险虽可控，但必须有意识地进行管控。组织应盘点其软件组件，在显示漏洞状态的同时标注其生命周期状态，然后采用一个包含四种选项的决策框架：将迁移作为长期目标，将商业延长支持或补偿性控制措施作为过渡方案，仅对范围狭窄且设有有效期的例外情况接受风险。

‍

从基本概念到漏洞生命周期及建议，这本电子书介绍了开源软件中漏洞的最新状况。

‍

引言

在过去的二十年里，绝大多数时间里，漏洞管理都遵循着一种平稳的节奏。研究人员或供应商发现一个缺陷或漏洞，系统会分配一个CVE编号，安全扫描工具会将其标记出来，随后发布补丁，而各组织则会逐一处理待处理事项，部署这些补丁。这个过程从来都不算快，但如今披露的漏洞数量却比以往任何时候都多。

‍

该数据集的构成与其规模同样重要。CVE编号机构（CNA）的生态系统已发生转变。随着专注于第三方生态系统和开源领域的专业CNA的涌现，漏洞披露不再由少数拥有成熟安全计划的大型供应商主导；它已成为一个由人工智能辅助发现技术驱动的、分布式且高吞吐量的流程。

‍

据CSA称，从漏洞披露到确认遭到利用的平均时间已缩短至仅5天。根据《2026年应用安全状况报告》 ，2025年针对网站漏洞的攻击达到62.9亿次，同比增长56%。 与此同时，大多数组织所遵循的合规时限（例如PCI DSS第6.3.3条规定的30天整改期限）制定于攻击者需要数周甚至数月才能将披露的漏洞武器化的时代。如今，攻击者的行动速度通常已超过最快的强制性整改时限。 对于已被弃用、不再受支持或已达到生命周期终止（EOL）的开源软件，由于不存在补丁，因此也不存在补丁窗口。出于实际考虑，本文将所有此类无人维护的软件统称为 EOL 软件：即不再获得安全修复、新版本发布或任何形式补丁的软件。

‍

这本电子书探讨了如何在这个新现实中开展工作：充分了解漏洞，从而为任何使用开源软件的组织制定策略。

‍

漏洞、弱点和利用手段

有效的风险管理需要工程、安全和治理团队采用统一的术语体系。不同的术语在不同的数据库和系统中可能对应不同的对象，若将它们混淆，可能会导致误解、资源错配、虚假自信，并最终引发安全风险。

‍

错误、缺陷、漏洞和利用

漏洞是指导致软件行为异常的任何缺陷。大多数漏洞不会引发安全后果。弱点是一类可能导致安全问题的错误，例如未能验证输入长度。弱点被收录在由 MITRE 维护的“通用弱点枚举”（CWE）中。漏洞是指特定软件和版本中弱点的具体实例，攻击者可以实际利用该实例。 漏洞会被分配 CVE 标识符。利用程序是指能够将漏洞转化为系统被攻破的可运行代码或技术手段。一个漏洞可能存在多年却没有公开的利用程序，而一旦利用程序被公布，其风险等级（严重性）便会在一夜之间发生变化。理解这些不同的概念对于确定修复工作的优先级至关重要。

‍

主要安全缩写词

CVE（通用漏洞与暴露）是公开披露漏洞的全球性数据库，由MITRE在美国政府资助下运营（cve.org）。 每条 CVE 记录都确立了唯一标识：一个 ID 对应一个漏洞，从而确保每款工具、每份安全公告以及每场讨论所指的都是同一个漏洞。CVE ID 由 CVE 编号机构（CNA）分配，该机构是一个由供应商、开源项目、安全公司及协调员组成的联盟，经授权可在各自管辖范围内分配 ID。HeroDevs 就是一家 CNA。

‍

NVD（国家漏洞数据库）是NIST在CVE基础上构建的数据增强层（nvd.nist.gov）。NVD补充了CVSS评分、CWE映射以及受影响产品（CPE）数据。近年来，NVD在数据增强方面积压了大量工作，这也是许多项目不再将其视为唯一权威信息来源的原因之一。

‍

EUVD（欧盟漏洞数据库）是由欧盟网络安全局（ENISA）维护的一个集中式平台，用于追踪、分类和处理与欧盟相关的软件和硬件漏洞。 该平台旨在支持《NIS2指令》和《网络韧性法》，它不仅整合了全球数据源（如CVE和NVD），还直接接收来自欧洲各国计算机安全事件响应团队（CSIRT）的报告以及区域供应商披露的信息。 

‍

由 FIRST 维护的CVSS（通用漏洞评分系统）根据可利用性和影响指标，采用 0 到 10 的评分标准来衡量漏洞的技术严重程度（first.org/cvss）。CVSS v3.1 和 v4.0 的评分标准有所不同。该评分并未说明是否有人正在实际利用该漏洞，也未说明您的部署环境是否可被访问。

‍

EPSS（漏洞利用预测评分系统），同样由FIRST开发，用于估算某个漏洞在未来30天内被实际利用的概率（first.org/epss）。EPSS表示的是概率，而非严重程度。一个严重程度较低的漏洞可能获得较高的EPSS分数，反之亦然。

‍

KEV（已知被利用漏洞目录）是美国网络安全与基础设施安全局（CISA）发布的权威漏洞清单，其中列出了已在实际环境中被确认利用的漏洞，每项漏洞均规定了美国联邦机构必须完成的修复截止日期（参见cisa.gov 上的 KEV 目录）。KEV 是任何优先级排序方案的最低标准：如果某项漏洞既在 KEV 目录中，又存在于您的环境中，则应将其列为优先处理事项。

‍

SBOM（软件物料清单）是软件内部组件的机器可读清单，通常采用 SPDX 或 CycloneDX 格式。CISA 负责维护 SBOM 指南和社区资源的中央汇编库（cisa.gov/sbom）。

‍

VEX（漏洞可利用性交换格式，Vulnerability Exploitability eXchange）是一种配套格式，允许供应商说明其产品组件是否实际受到特定 CVE 的影响。VEX 的出现是因为 SBOM 会生成大量理论上的匹配结果，而必须有人来明确哪些匹配结果真正重要。

‍

咨询行业概况

CVE 记录和 NVD 条目仅是整体情况的一部分。供应商安全公告通常包含最早且最准确的受影响版本信息。开源生态系统维护着各自的安全公告数据库，包括 GitHub 安全公告数据库和 OSV.dev 聚合层，这些数据库在版本范围和严重性评级方面往往与 NVD 存在差异。

‍

零日漏洞和永久漏洞

“零日漏洞”是指在供应商或维护人员得知该漏洞或发布修复程序之前，就已经存在可利用该漏洞的攻击手段的漏洞。有些漏洞的影响如此之大，以至于有了专属名称：Spring4Shell、Dirty Pipe、Log4Shell、Shellshock、Heartbleed，尽管其中一些漏洞在公开披露后的几天内就已发布了修复程序。

‍

“永恒漏洞”（forever-day）是指已达到生命周期终止（EOL）的软件中存在的漏洞。由于被弃用、不再受支持以及已达到生命周期终止的软件无法获得安全修复、不会发布新版本，也无法获得补丁，因此“永恒漏洞”被利用的风险更高。除非运维人员采取除等待补丁之外的其他措施，否则该漏洞在每个部署环境中都将无限期地处于可被利用的状态。 确定库存中的哪些组件实际上已越过这一界限本身并非易事，因为大多数开源软件包从未正式宣布过 EOL。

‍

根本原因：漏洞是如何进入代码的

漏洞很少是出于恶意而进入代码的；软件的复杂性、遗留依赖关系以及现代软件交付的速度，不可避免地会带来系统性风险。绝大多数漏洞都属于少数几种长期存在的类别，这些类别早已被人们所理解、记录并传授。

‍

内存损坏。包括缓冲区溢出、释放后使用、双重释放以及越界读写等，主要集中在 C 和 C++ 代码库中。这些漏洞在操作系统、浏览器和原生库中仍占主导地位，也是业界推动 Rust 等语言（由 CISA、NSA 等机构倡导）实现内存安全的主要目标。

‍

注入。SQL注入、命令注入、LDAP注入和XML注入都有一个共同的根本原因：在数据与代码之间缺乏充分隔离的情况下，由攻击者控制的数据进入了解释器。自该列表20多年前发布以来，注入漏洞一直出现在每一版的OWASP十大安全风险中。

‍

跨站脚本攻击（XSS）。 仅在2025年，XSS就导致了超过 8,000个CVE。尽管XSS已被发现三十余年，但它依然存在：一方面，在Web应用程序将用户数据写入页面的成千上万个位置中，任何一个环节都容易在输出编码时出错；另一方面，准入门槛较低的生态系统不断产出新代码，这些代码重复着旧有的错误。

‍

反序列化。对攻击者提供的数据进行不安全的反序列化，会导致有史以来最严重的远程代码执行漏洞，特别是在Java和.NET 生态系统中，丰富的对象图可能会被转化为“小工具链”。

‍

身份验证和访问控制缺陷。访问控制缺陷是当前 OWASP 前十大安全漏洞中的首要类别。信任边界缺失、授权设计不完善、不安全的默认设置以及不安全的 API 使用都会导致漏洞，而这些漏洞是任何内存安全的编程语言都无法预防的，因为它们是设计缺陷，而非实现缺陷。

‍

加密技术的误用。很少是算法本身有缺陷；几乎总是因为正确算法被错误使用：硬编码密钥、禁用证书验证、自建方案、随机性不足。

‍

语言与生态系统风险概况

每个主要的生态系统都会以各自独特的方式出现故障。众所周知，C 和 C++ 代码库容易引发内存损坏问题：包括缓冲区溢出和越界访问漏洞。

Java 的漏洞特征在于不安全的反序列化以及复杂的框架级缺陷，而Spring 生态系统则体现了其规模之大：仅 2026 年 6 月就出现了67 个Spring CVE，其中 27 个属于高严重性漏洞。

‍

JavaScript 和 npm 生态系统中的许多漏洞都是由于供应链暴露和原型污染导致的，而极深的依赖深度进一步加剧了这一问题。2026 年 5 月的“Mini Shai-Hulud”攻击活动便是最近的一个典型案例：攻击者通过污染 GitHub Actions 缓存，在六分钟内向 42 个 TanStack 包中发布了 84 个恶意版本。

‍

PHP 代码容易产生注入和文件包含漏洞，这些漏洞主要集中在 WordPress 和Drupal 的插件生态系统中。Python 则容易引发反序列化（pickle）漏洞、依赖混淆问题，以及日益增多的 AI 和机器学习工具中的漏洞。

‍

了解您技术栈中常见的漏洞，有助于您针对生态系统中容易出现问题的环节合理分配审查精力；不过，任何类型的漏洞都可能在任何语言或框架中随时被发现。

‍

进一步了解

有两份参考资料对本章中涉及的预防方面进行了比电子书更为详尽的阐述。OWASP 应用程序安全验证标准（ASVS）是用于验证应用程序级控制措施的工作检查清单。NIST 安全软件开发框架 SP 800-218定义了开发生命周期实践，监管机构越来越频繁地直接引用该框架。 

‍

漏洞的端到端生命周期

每个漏洞都有一个生命周期，从形成、发现，到披露，再到（理想情况下）修复。了解这一过程——包括可能出现停滞或中断的环节——是应用程序安全知识的基础。

探索之路

漏洞主要通过四个渠道显现，每个渠道都有不同的特点。

‍

内部研究。供应商和开源项目的安全团队审查自身代码、运行静态分析，并对自身目标进行模糊测试。信号最强，且出现在生命周期最早阶段。

‍

漏洞赏金计划与外部研究人员。独立研究人员通过HackerOne等平台的项目提交漏洞报告，或直接向维护者报告。报告质量参差不齐；例如，近期由人工智能生成的低质量报告已将这一渠道推至崩溃边缘，受影响的开源项目包括Node.js等。HeroDevs最近的一次网络研讨会曾就此进行过讨论。

‍

大规模模糊测试。像谷歌的OSS-Fuzz这样的覆盖率引导型模糊测试基础设施，持续对数百个关键开源项目进行测试，在其运行期间已发现数万个问题。

‍

AI辅助分析。这是最新兴且发展最快的领域。前沿语言模型现已能够阅读代码库，推测可能出现故障的位置，通过运行中的软件对这些假设进行实验验证，并得出经证实且可重复的结果。Anthropic的Mythos Preview评估报告仅基于其中一个大型语言模型，便提供了详尽的证据。

‍

验证与报告

在经过验证之前，一个发现还不能算作漏洞：必须在实际软件上复现该问题，并明确说明其影响范围和受影响的版本。从“我的工具标记了这个问题”到“这是一个可复现且影响已得到证实的安全问题”之间的差距，正是大多数低质量报告止步之处，也是报告者赢得公信力的关键所在。 

‍

一份优质的报告应包含受影响的组件及版本范围、复现步骤或概念验证、影响评估，以及附有理由说明的建议严重程度。Anthropic 发布的关于 AI 发现漏洞的运作原则提供了一个有用的现代模板：每份报告都经过人工审查和确认，由 AI 发现的漏洞会明确标注来源，并在可能的情况下附上候选补丁（Anthropic，《协调漏洞披露》）。

‍

协调披露、禁令及时间表

协调漏洞披露（CVD）是一种经协商达成的流程，通过该流程，漏洞报告者会给予供应商或维护者时间，使其在漏洞细节公开之前开发并发布修复程序。该流程的权威参考文档是《CERT/CC协调漏洞披露指南》，其基础标准为 ISO/IEC 29147（披露）和 ISO/IEC 30111（处理流程）。

‍

业界的事实上的惯例是90天的披露期限，即记者在90天后或补丁发布后（以较早者为准）进行披露，具体期限的延长或提前则需根据具体情况协商确定。设置披露禁令期是为了协调多家供应商的修复工作，特别是针对共享组件中的漏洞，此类漏洞往往需要数十款下游产品同时进行补丁修复。

‍

披露规范的前提是，另一端有人有能力开发修复程序。对于一个健康且活跃的项目，其生命周期会完整地走完：报告、禁令、补丁、安全公告、采用。而对于已终止维护的开源项目，其生命周期则会提前终结。 既无人可向其报告，或者收到报告的维护者会准确地指出该发布分支已不再受支持。披露流程就此完成；而修复工作却从未开始。这就是为何不受支持和已终止支持的软件会永久积累未修复且公开记录的漏洞的根本原因：披露仍在持续发生，而修复工作却已停止。 

‍

清晰地公布长期支持计划和产品生命周期结束（EOL）日期，是向软件开发人员提供透明度的推荐最佳实践。HeroDevs 通过其“开源可持续性基金”为开源项目发布的框架，从维护者角度解决了这一问题：通过官方渠道通报产品生命周期结束事件，记录哪些版本受支持、哪些不受支持，并在产品生命周期结束日期到来之前，引导用户进行迁移或采用支持方案。

‍

补丁发布与公开披露

当生命周期机制正常运作时，最终结果是发布补丁并附带一份安全公告：其中包含修复方案、受影响的版本、严重程度以及对报告者的致谢。遗憾的是，攻击者可以利用这些披露信息，针对未打补丁的环境发起攻击并加以利用。 根据CSA的数据，从漏洞披露到被利用的五天中位数时间窗口，会为所有尚未更新的部署系统敞开大门。而对于已达到生命周期终止（EOL）的开源软件，除非您选择商业扩展支持方案，否则永远不会收到补丁。

‍

已停止维护的开源软件中的漏洞

当前的漏洞管理实践及监管机制，都建立在一个隐含的假设之上：对于任何给定的漏洞，都存在或即将存在修复方案，而运维人员的职责就是迅速部署该方案。已达到生命周期终止（EOL）的软件则彻底打破了这一假设。

‍

被弃用、不再受支持或已达到生命周期终止（EOL）的开源软件，是指那些不再由原始开发者或社区积极维护或支持的项目。这些项目不再获得安全补丁、错误修复或兼容性更新，导致组织面临已知漏洞的风险，并增加了出现安全和运营问题的风险。针对这些项目发布的每个CVE漏洞，都无法通过常规渠道得到永久修复。 

‍

在自有库存中查找已停产（EOL）元器件

如果不清楚该风险类别所在的位置，就无法对其进行管理，而大多数漏洞扫描工具无法解答这个问题，因为它们是基于 CVE 数据而非生命周期状态进行分析的。一个既无已知 CVE 条目又无剩余维护者的组件，在安全扫描工具看来似乎毫无问题，但实际上却是一颗定时炸弹。

‍

为弥合这一差距，现已出现了支持生命周期管理的工具。HeroDevs EOL 数据集通过一个追踪所有主要生态系统（npm、Maven 等）中超过 1900 万个包版本的数据集，对各包进行核查，并针对每个组件返回 EOL 判定结果。为了实现全面完整的平台功能，HeroDevs Evergreen会自动为应用程序中的每个 EOL 依赖项提供由工程师构建且经过安全验证的替代方案。这些替代方案以拉取请求的形式提交，供审核和合并。随着后续更多依赖项失去支持并被纳入系统，该平台将持续扩展覆盖范围。

‍

决策树：迁移、缓解、接受或购买延长支持服务

一旦确定某个组件已达到生命周期终止（EOL），则共有四种选择。

‍

• 迁移。迁移到受支持的版本或替代技术。这是永久性的解决方案，也是正确的长远之计，但框架级依赖项的实际迁移需要以工程师冲刺周期来衡量，而在发现关键CVE后强行在紧急时间表内完成迁移，是成本最高的方式。强制迁移还会对组织或业务的运营造成影响。

‍

• 缓解风险。采取补偿性控制措施：WAF规则、网络分段、功能禁用，甚至环境隔离。作为过渡方案是可行的，但作为最终解决方案则存在风险，因为每项控制措施虽然针对已知CVE的已知利用路径，但其底层漏洞以及所有尚未发现的漏洞依然存在。

‍

• 接受。记录该风险并有意识地承担。对于真正孤立且价值较低的系统，这种做法有时是站得住脚的。但对于任何面向互联网或处于受监管行业的系统，这种做法极少能站得住脚。一些监管制度实际上已排除了这种选择。

‍

• 第三方扩展支持。通过专业的安全工程团队，对已停用的开源软件提供商业维护。HeroDevs 聘请了开源专家和核心贡献者，他们持续监控上游安全公告，并针对客户的已停用版本评估 CVE 漏洞。他们开发、测试并发布回溯修复程序，作为可直接替换的解决方案，无需修改应用程序代码。 当某项备受关注的 CVE 并不适用于已停用的软件时，同样的专业能力也能发挥反向作用。2026 年，Drupal 核心组件披露了一个高度危急的 SQL 注入漏洞，但上游安全公告并未评估Drupal 7 版本；最终，HeroDevs 的专家通过对核心组件和贡献模块进行审计，才确认Drupal 7 的部署并未受到影响（HeroDevs 博客：《Drupal 7 是否受到 CVE-2026-9082 影响？》）。

‍

这四种选项并非互斥；常见的成熟模式是：以延长支持或缓解措施作为过渡，以迁移作为最终目标，而“接受”仅适用于明确限定且设有有效期的例外情况。

‍

合规风险

有必要进行专门的合规性分析。HeroDevs 的白皮书， 《开发人员安全合规指南》，深入探讨了全球标准、框架和法规，并得出结论：已停止支持（EOL）的软件在以下三个主要方面本质上无法满足其核心要求：

• 修复时间表：标准合规期限（例如针对关键漏洞规定的30天强制修复期限）默认假设已存在补丁。
• 库存与资产可视性：生成软件物料清单（SBOM）后，处于活跃状态但已不再受支持的组件将立即受到监管审查。
• 有据可查的治理：对于没有明确修复路径的漏洞，无法满足规定的风险管理流程要求。

因此，如果审计员发现范围内存在一个已停产（EOL）组件，且该组件存在未修补的严重CVE漏洞，则很可能记录为不符合项。

‍

基于人工智能的漏洞发现与利用

最有力的公开证据来自Anthropic的安全研究团队，该团队在经过约一个月的内部测试后，于2026年4月发布了对其Claude Mythos Preview模型的技术评估报告。 该模型通过阅读代码来构建假设，运行软件以验证或推翻这些假设，根据需要使用调试器，并输出经过验证的结果。借助这种方法，该模型在广泛使用的开源软件中发现了真实的零日漏洞（主要是内存安全漏洞），并展示了构建有效漏洞利用程序的能力，包括将多个浏览器漏洞串联起来（Anthropic，《评估Claude Mythos Preview的网络安全能力》）。

‍

规模是关键所在。Claude Mythos 以及 OpenAI、谷歌等公司开发的同类大型语言模型（LLM）能够快速扫描代码库并识别漏洞。与此同时，人工智能辅助工具虽能帮助研究人员加快修复进度，但速度无法与之匹敌。而这仅仅是整个流程中涉及编码的部分。修复方案仍需经过分类、打包、文档化、测试，并最终发布。

‍

漏洞利用

Wiz对Mythos测试结果的分析指出，该模型能够以CVE标识符和提交哈希值作为输入，并在数小时内以较低成本自主生成可运行的漏洞利用代码，而过去，这项工作通常需要经验丰富的研究人员花费数天至数周时间才能完成。其实际影响是：更多CVE漏洞将被更快地披露并被利用。借助人工智能的辅助，每一个已公开的漏洞修复方案都可能成为开发漏洞利用代码的起点。

‍

现在将这一情况套用到被弃用、不再受支持或已达到生命周期终点（EOL）的软件上，这种不对称性就显得尤为突出。对于受支持的软件，攻击手段的加速会得到补丁更快的发布作为回应；虽然防御者的应对窗口在缩小，但仍然存在。而对于被弃用、不再受支持和已达到生命周期终点（EOL）的软件，则根本不存在防御者的应对窗口，因为根本没有补丁可供赶在漏洞被利用前及时修复。 

‍

人工智能已彻底颠覆了防御方的优势。前沿模型如今能够以机器级速度和边际成本，自主进行漏洞研究并生成攻击代码。对于仍在运行的软件而言，这缩短了打补丁的时间窗口；对于已停产（EOL）和无人维护的软件而言，这则彻底消除了防御能力，将遗留的技术债务转化为实际的入侵风险。

‍

如果该行业的发现率即将因机器级分析而成倍增长，那么那些在结构上无法修复的软件群体，正是这种增长造成最大破坏的地方。这正是将“产品生命周期结束（EOL）”库存视为一项紧迫的、需由董事会层面处理的议题，而非背景性的技术债务，这一观点最有力的论据。

‍

最终想法

旧有的漏洞应对策略基于三个假设：漏洞披露的节奏处于可控范围内；已有补丁或即将发布；防御方有时间部署补丁。如今，这三点均已不成立。在新的漏洞格局下，根据FIRST的年中预测，漏洞披露量正逼近66,000例；人工智能辅助的漏洞发现正以机器般的速度将代码库转化为漏洞发现；而漏洞利用窗口的中位数已缩短至低于所有合规时限。

‍

对于受支持的软件而言，这是一个棘手的运营问题。而对于已停止支持（EOL）的软件来说，情况则要严重得多：一类日益增多的漏洞已被公开记录，且永远无法修复，同时正被人工智能不断发现。本书所述的每一种加速趋势——更多CNA、更多发现、更快的利用——对那些在结构上无法获得修复的软件造成的打击最为沉重。

‍

应对之策并非惊慌失措，而是要进行盘点和排序。明确技术栈中哪些组件已超过产品生命周期终止（EOL）期限（大多数厂商从未公开宣布这一点）。在同一视图中，将生命周期状态与漏洞状态并列显示。然后有条不紊地应用决策树：以迁移为最终目标，以延长支持或缓解措施作为过渡方案，仅在存在明确截止日期的有限例外情况下才予以接受。

‍

人工智能发现的漏洞频发，正使已停用（EOL）软件的风险成倍增加。“永恒漏洞”（Forever-days）只有在无人发布修复程序的情况下才会“永存”。HeroDevs“永无止境的支持”服务为40多个已停用的开源框架、运行时环境和库恢复了安全补丁支持，并根据服务水平协议（SLA）提供即插即用的替代方案。如果贵方库存中的任何组件已超过停用期限，请在下一轮漏洞披露周期将其曝光之前，与我们的团队联系。

‍