AI 挖洞越来越快，为什么企业的漏洞还是修不完？

原创

小智
小智

智榜样网络安全学习中心

2026年10月13日 22:00
湖南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

近两年 AI 在漏洞发掘方面的进展确实十分明显。

以往开展代码审计时，安全工作人员需逐一追踪函数的调用情况，检查参数的处理状况以及分析权限的校验状况，即便盯一段代码观察半天，也难以明确问题的出处。当下借助大型模型以及自动化解析工具，科研人员能够更快地找出可疑代码，构建测试的用例，还能够让 AI 试图编写漏洞的复现步骤以及修复的补丁。

听起来企业安全方面的问题应该更加容易解决。

但是现实并非如此简单。企业内部漏洞工单的发现速度较快，却未能及时清除掉。每日安全团队都会收到新扫描的结果。开发人员在处理历史的问题的时候，测试的团队还得去验证补丁有没有对业务产生影响。一批修完之后，下一批扫描又出现了一批。

AI 正在削减发现漏洞所需的成本，但是并没有自动把修复漏洞消除掉。

一、AI 已经能找到很多问题，但“找到”不等于“确认”

先看一组近期数据。

在2026年10月的时候，Anthropic 发布了针对开源软件开展的 OSSScanner 漏洞发掘的相关计划。该公司表示过去的六个月里运用模型去扫描开源的项目，找到了超过 29, 000 个的候选漏洞，可是人工仅仅完成了大约 6, 000 的结果审查以及分流。

注意，此处有 29, 000 个属于候选漏洞情况，并不意味它们全部已经确认是有效的。官方同样明确表明，未经人工审查以及分流过的模型相关报告，极有可能出现错误或者无效的结果。

在实际项目里，扫描结果至少还要经过几道判断：

• 问题是否真实存在：

AI所指出代码路径，在实际进行运行的时候能否被触发？
* 攻击条件是否成立：

相关接口有无对外开放，攻击者有无需登录？是否存在权限或者网络的限制？
* 问题是否已经修复

：可能早就存在补丁，仅仅是当下的分支，依赖的版本或者扫描的规则没有被识别出来而已。
* 影响到底有多大：

同样是输入校验问题，出现在公开接口和内部管理功能中，实际的风险或许完全不一样。

假设AI发现某段代码未对用户输入进行充分检查，并且判定该代码可能具有SQL注入的风险。此为良好调查起始点，但是安全人员需确认输入能否被控制，数据是否陷入危险SQL拼接进程以及实际情境中是否有可利用途径。

要是没有经过验证就把每一条AI的结果当作高危的漏洞派发到开发团队那里，漏洞的数量就会增多得很快，实际需要优先解决的问题就容易被忽略掉。

二、漏洞越找越多，企业的处理能力却是有限的

众多企业安全流程依旧处于一个前提状态：扫描器具每次出现若干问题，由安全人员确认，由开发团队修改，最终由测试人验收。

当扫描的频率不高，漏洞的数量有限的时候，这种办法还可以。但是AI让漏洞察觉的速度变快。以往需要人工耗费较长时间去检查代码的情况，现在能够批量地进行分析；以往依靠研究人员一个一个地研究组件的情形，当下也可能会被自动化的工具反复地扫描。

要是发现速度提升了好几倍，而且验证以及修复环节依旧依靠原先的人员配备，积压就容易产生。

更麻烦之处在于，企业所面临的并非仅仅是AI新发现的难题。一个业务系统或许同时有旧版本的依赖，历史留存的代码，配置出现错误，权限设计存在缺陷以及多年没有进行升级的部件。上个季度安全团队正在处理工单的新扫描结果。

这并非仅仅依靠几个人就可以全部解决的事情，由于漏洞的处理涉及许多团队，任意一个环节没有跟上，都会产生新的等待的队列。

三、漏洞扫描报告越来越长，真正的风险却不一定更清楚

还存在一个常常被忽视的问题：漏洞的数量并不等同于企业真正面临着的风险。

不同的工具可能会重复去报告同一个问题，同样的漏洞也许会出现在好几个依赖包，多个应用的版本或者多个资产的上面。要是没有一样的资产以及漏洞管理的机制，那么安全团队就很容易碰到此类情况：同样是依赖漏洞的话，代码扫描就报一次，还有软件成分的分析工具分析，其他的扫描工具再一次。开发团队为应对三个问题而开展工单生成，最终发现它们或许指向同一根因。

另外，CVSS 的严重程度评分也不可以单独去决定全部问题的解决顺序。

若相关组件没有部署到生产环境里，或者攻击路径严格受到限制，它的紧急程度或许低于另外一个评分较低，但已经存在公网并且有实际应用迹象的情况。

比较合理的做法，是把几个因素放在一起看：

• 漏洞是否已经被公开利用，或者存在可信的利用证据；
• 受影响资产是否对外开放，是否承载关键业务；
• 攻击者是否能够到达存在问题的代码路径；
• 是否存在可用补丁、缓解措施，以及实施修复的业务风险。

企业实际需要的并非是一份更为长久的漏洞列表，而是能够助力团队解答“哪些情况当下需要处理”此类风险排列情况。

四、最难的部分，往往是修复，而不是发现

假设 AI 已经确定某一开源组件有漏洞，并且生成修复方面的建议，是否直接运用补丁就能够了？

在简单的项目当中，答案或许是可以的。但是在真实的业务里面，组件进行升级或许会改变 API 的行为，对代码进行修复可能会对旧版本的兼容性产生影响，补丁也有可能带来新的逻辑方面的问题。某漏洞即便仅需修改若干行代码，也极有可能关联业务负责者的确认，代码的评审，自动化的测试，灰度的发布以及回滚的方案。

例如，企业发现一个第三方 Java 依赖存在漏洞。开发团队检查后发现，新版本虽然修复了问题，却同时调整了其他接口行为。业务系统依赖旧版本的一些特性，直接升级可能导致功能异常。

此时，安全团队不能只说一句“请尽快升级”。团队还得评估是否可以升级到兼容版本，是否需要回移补丁，是否存在临时缓解措施，以及修复之后如何验证。

这也是为什么漏洞管理经常出现“报告已经发出，工单一直没关闭”的现象。

2026 年 10 月，关于 IBM 和 Red Hat 的 Project Lightwell 的报道也强调了旧版本 Java 库修复的重要性。针对仍在使用的旧版本，能否提供适配且经过验证的补丁，同样是漏洞治理的一部分。企业采用具体修复方案前，仍应以项目方的公告和补丁说明为准。

五、企业应该怎么做？别再只盯着漏洞总数

如果企业已经引入 AI 代码审计、自动化扫描或 AI 渗透测试工具，接下来更重要的不是一味增加扫描频率，而是把发现、验证、修复和复测串起来。

首先，将重复的结果进行合并操作。

当同一根因在多种工具中多次被报告时，需尽量关联同一漏洞的记录，并留存受影响的资产，依赖的版本以及修复的状态。切勿让开发者在许多系统中频繁处理同一问题。

第二步，对候选漏洞以及已经确认漏洞进行区分。

AI 的输出能够进入需要验证的队列，但是不可以默认全部都成立。针对高危的结果，需要优先去补充复现的步骤，受影响的范围以及攻击的条件；针对证据匮乏的情况，先验证后派发，而非直接依据最高风险级别进行处理。

第三步，按照真实风险来设定修复的顺序。

优先应对存在实际运用迹象明显，暴露程度高，影响重要业务且具备可行修复办法的情况。其余漏洞也需进入清晰的处理时间段，不可因暂时不紧迫就永远搁置。

第四步，使得修复过程具备负责人以及期限。

漏洞可不能仅仅局限于安全团队扫描的平台里面。每一个需要进行修复的事情都得厘清责任团队，处理的时间，临时缓解的办法以及验收的标准。对于没办法按时修复的情况，得记录原因，风险接受的人还有后续复查的时间。

第五步，在修复之后必须要进行复测。

代码得以提交，并非意味漏洞已消失；依靠升级已经完成，也并非所有部署的环境都已经更新。需借助复测，版本核对以及其他能够验证的方式确认问题已经得到解决，并且要检查修复有无引入新风险。

六、AI 应该帮助企业缩短闭环，而不只是制造更多发现

AI于漏洞管理方面所具有的价值，不只是通过一次扫描就能够找出许多问题。

要是它可以进一步助力安全团队进行重复，补充复现的证据，分析影响的范围，生成修复的建议，辅助去编写测试的用例，再和现有的工单以及发布的流程相互连接，才有可能真正降低积压。

当然这并不意味把修复的权限都交给AI就可以解决问题了。自动产生的补丁或许存在不足之处，模型也有可能错误地去判断业务的逻辑。关键业务发生变更，仍需代码审查，测试以及必要的人工审批。

对安全团队工作成效进行衡量，也不应仅仅看本月所扫描出的漏洞以及生成的报告数量。更值得留意的指标包含：

• 高危漏洞

从发现到确认的平均时间；
* 从确认到修复完成的平均时间；
* 超过修复期限仍未处理的问题数量；
* 重复、误报结果占比；
* 修复后复测通过率；
* 已确认漏洞在关键业务资产上的剩余暴露情况。

这些不一定是越少越好的，还得结合资产的规模，业务的类型以及漏洞的风险一起去进行判断。但是它们至少和单纯统计发现多少漏洞更加接近真实安全的成效。

写在最后

AI 挖洞越发迅速，它自身并非企业漏洞累积而成的消极消息。反过来它让以往难以察觉的某些问题有了更早地显现出来。

真实的问题在于企业是否具备接住这类发现的能力。

当漏洞察觉从匮乏的 AI 转变为越发容易获取的自动化智能时，安全事宜的关键也会逐步发生转变：不仅要明确哪里存在不足之处，还要判定哪些问题有必要优先解决，如何在无影响业务时修复以及如何证实风险确实降低。

漏洞扫描最终的目标并非生成报告而是实现对真实风险的把控。

要是 AI 只是去做漏洞清单，企业就会更加忙碌；只有它可以帮助团队更快地完成验证，决策以及修复的全部流程，漏洞的积压才有可能真正地减少。

🎁 互动与福利

分享本文到朋友圈，点赞+在看+关注，一键三联，可以凭截图找老师领取

上千学习资料+工具哦

分享后扫码加我！