开源维护者收到的漏洞报告比他们能够采取行动的要多，现在越来越多的份额来自以机器速度运行的人工智能系统。今年春天大约两个月，Anthropic的Claude Mythos Preview梳理了超过23,000条开源代码路径，并将经过验证的发现路由到拥有它们的项目。Tuskira研究了这些发现一旦到达人手中会发生什么。
该计划报告了1,596个经过验证的漏洞，在大约九周的窗口内分布在数百个项目中。六家外部安全研究公司在将调查结果提交到维护者之前进行了分类。
调查结果在审查中保持不下。外部公司证实，他们检查的子集的真阳性率为90.8%，这表明交易量反映了真正的错误。严重性是更柔和的边缘。人类和供应商审查员在超过一半的案例中就确切的严重性达成一致，几乎每次都在一个级别内，模型分级问题比维护者更关键。Anthropic本身将已确认的真正阳性描述为影响的衡量标准之一，并指出补丁计数是更有说服力的滞后指标。
问题在披露后开始。发现每天大约有25个经过验证的漏洞，贷记修复接近1.5个。Tuskira将这种不平衡提炼成大约16.5比1的单一比例。
研究人员称日益增长的积压为脆弱性赤字。每天，该计划交给维护者的发现比他们明显关闭的要多得多，而未决问题堆积扩大了大约二十几个。该公司写道：“企业需要按照发现节奏运营，而不仅仅是按照补救节奏运营。”
维护者本身是响应的。确认报告的中位数时间接近五分之一。承认和修复相距甚远。大约6%的已披露漏洞在快照中携带了上游补丁，研究人员将这个数字视为下限，因为一些维护者悄悄地修复了。
第二个延迟位于维护者的下游。咨询数据库需要时间来摄取修复，商业扫描仪需要时间来刷新，企业需要时间来测试补丁，然后再进入生产。一旦咨询公开，大多数项目就会开始认真工作。大约95%的Mythos披露在快照日期没有公开咨询。在报告的结构估计中，从私人披露到部署企业修复的时间在三到五个月之间。
部署补丁本身就有危险。修复内存安全错误可能会改变时间。更严格的输入检查可以拒绝以前有效的有效负载。依赖性升级可以强制进行一连串的版本更改。普通语言包的验证通常运行两到六周，对于嵌入式、加密或受监管的组件则更长。在此期间，漏洞可能是公开的，漏洞工具可能会流通，生产可能仍然运行旧代码。
一次上游的发现很少保持警惕。单个ImageMagick缺陷可以传播到18个或更多下游软件包变体，分发重建在许多单独的提要中携带仅源代码修复。对后卫来说，重要的计数是生产中每个可触及的受影响实例，其爬升高于上游统计。
Tuskira的回答将修补重新定位为一个决策问题。其模型基于四个问题：脆弱的代码路径是否在生产中运行，谁可以访问暴露的实例，环境是否显示出主动利用的迹象，以及现有控件是否已经阻止了漏洞。这些答案将每个发现都引导到紧急车道、分阶段车道或有记录的延期。
一个有效的例子说明了这一点。nginx的一个严重缺陷可能威胁到整个舰队，如1200例所示。连续的过滤器迅速缩小了该人群。计算编译的模块、启用的功能、易受攻击的配置和公开曝光，留下三个公共的、未经身份验证且缺少Web应用程序防火墙的实例。緊急行動適用於這三個人。其余的通过记录的推理在较慢的车道上移动。
模式通过任何单个程序到达。OSS-Fuzz在九年的运营中记录了13,000多个漏洞，Mythos在短时间内达到了该语料库的有意义的一小部分。越来越多的人工智能发现工作正在上线，这提高了整个生态系统中发现节奏更高的前景。
CVE提要现在延迟到达，有用的信号更早地出现在上游提交、透明度日志更改和咨询信用的证券公司中。阅读早期信号，并提前知道哪些依赖项在生产中运行，正在成为工作的核心。
原文链接地址：https://www.helpnetsecurity.com/2026/07/02/open-source-ai-patch-gap/
