AI说91.5%高危，维护者只认51.3%：漏洞定级这活儿，为什么还是离不开人？

安全牛

2026年10月12日 12:11
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

点击蓝字 关注我们

预想中的\"末日\"没来，但新问题来了

说到AI找漏洞，大家最担心什么？很多人觉得会出现\"漏洞末日\"——AI疯狂挖漏洞，攻击者手里的武器越来越多,防守方根本应付不过来。

2026年4月Anthropic推出Project Glasswing时，这种担忧达到了顶峰。但五个月后的数据告诉我们，事情并不是这样发展的。

AI确实能快速发现大量问题，但\"发现一个问题\"和\"这个问题值得修复\"\"这个问题能被利用\"\"这个问题该优先处理\"，完全是两码事。

真正出问题的不是扫描环节，而是扫描之后的人工分析、验证、定级、修复这些流程。简单说，AI没有解决瓶颈，只是把瓶颈往后推了。

一组震撼的数字：26000个发现，最后修了202个

Anthropic公布的数据非常直观：

• AI一共报告了26,153项发现
• 其中2,736项进入披露流程，占10.5%
• 2,096项报告给了软件维护者，占8%
• 最终只有202项真正修复了，占0.8%
• 还有245项被撤回了

看到了吗？这是个典型的漏斗。AI发现能力确实强，但越往后走，数量掉得越厉害。

Glasswing自己也承认：人工分诊已经成了整个流程的\"限速步骤\"。

这对中国企业意味着什么？以前我们担心扫描器不够强、漏报太多。现在问题反过来了——安全团队手里的发现远远超过了自己能处理的量。

真正稀缺的不再是扫描能力，而是安全专家的判断力。

AI可以7×24小时不停跑，可以同时分析海量代码，可以产生成千上万条线索。但最后企业还是得回答这些老问题：

• 这问题是真的吗？
• 真的算漏洞吗？
• 攻击者能利用吗？
• 部署环境是什么样的？
• 该给多高优先级？
• 修了会不会搞坏系统？

这些问题光靠\"发现数量\"回答不了。从Glasswing的结果看，AI放大的是数据供给，而不是团队处理数据的能力。这种供需失衡，是中国企业部署AI安全工具时最容易踩的坑。

发现漏洞≠攻击者能用上

26,153项发现已经够让安全团队头大的了。但换个角度问：这些AI找到的漏洞，有多少真的被攻击者用在实战里了？

答案让人意外：在1,061个AI辅助发现的漏洞中，只有14个被记录为真实利用，比例约1%。

这个数字很重要，它提醒我们必须区分\"漏洞存在\"和\"漏洞风险\"。发现了一个漏洞，不等于攻击者一定看得上，也不等于在实际环境里就能利用。

一个漏洞能不能真正造成威胁，还要看：

• 部署方式和版本
• 网络暴露面
• 权限要求
• 攻击路径复杂度
• 攻击成本和收益

当AI产生的发现进入数万级别时，如果把所有结果一视同仁，安全资源会被迅速耗尽。

对中国企业来说，这个问题更严重。很多企业安全团队本来就人手紧张，既要管传统IT资产，又要应对云原生、容器、微服务这些新架构。这时候如果引入一个能疯狂产生发现的AI工具，但没配套的分诊能力，很容易陷入\"数据越多越懵\"的状态。

AI说91.5%是高危，维护者只认一半

风险定级的差异更能说明问题。Claude判断91.5%的发现属于高危或严重级别，但软件维护者重新评估后，只认可其中51.3%。差了将近40个百分点。

这说明什么？如果完全照着模型的判断来修复，会浪费大量资源在被高估的问题上。

漏洞发现能力和漏洞语境理解能力，不是一回事。

软件维护者更懂项目的设计逻辑、API边界、使用限制和实际部署情况。AI能看到代码里的异常路径，但不一定理解\"这种行为是不是设计允许的\"。

curl项目的案例很典型。AI工具Mythos发现了5个问题，curl团队仔细分析后，真正算漏洞的只有1个。其他4个里，3个是假阳性（文档里早就说清楚了的设计限制），1个是普通Bug不是安全问题。最后那个漏洞，严重性也只是\"低危\"。

项目负责人Stenberg的态度很明确：这问题没严重到要让用户紧张的地步。

这给我们一个清晰的提醒：模型越强，不等于越不需要安全专家。很多时候恰恰相反——AI发现的越多，越需要专家帮它理解这些发现。

Red Hat怎么做的：把AI放进安全生产线

Red Hat的实践最值得学习。他们的安全架构师Michele Chubirka为OpenShift构建了一套完整的扫描框架，但关键在于——他们没把AI当成万能魔法。

Chubirka说得很直白：很多人以为部署个先进模型就能自动搞定一切，现实不是这样的。

Red Hat的实际流程是：

1) 先生成基础安全报告

2) 机器做初步分诊

3) 人工检查验证有疑问的结果

整个过程没有取消人工，只是把人放在了最需要专业判断的位置。

Chubirka提出了一个重要概念——VulnOps（漏洞运营）。

不是把漏洞当成阶段性任务集中处理，而是让漏洞发现、验证、修复变成持续运行的流程。AI带来的不是\"多了个扫描器\"，而是把漏洞管理从项目式工作推向了持续性生产模式。

Chubirka把这个比喻成\"工厂\"。当安全团队面对持续涌来的大量发现时，光靠个人经验和临时协作扩展不了。必须把漏洞处理标准化：

• 机器先干什么
• 专家什么时候介入
• 什么情况下升级
• 怎么验证
• 怎么生成修复
• 怎么测试
• 怎么回到开发流程

只有建立起这样的流水线，AI的发现能力才能真正转化为修复能力。对于正在搞DevSecOps转型的中国企业，这个\"漏洞工厂\"思维特别值得借鉴。

AI生成的补丁：60%能用，但40%有问题

Chubirka团队还让AI自动生成修复补丁，结果很能说明问题：

• 约60%基本可以直接用
• 约20%能工作，但不符合设计原则或编码规范
• 约20%明显不能用

对中国企业的DevSecOps团队来说，这个数据很有参考价值。60%可用说明自动修复确实有前景，但40%需要人工干预也说明不能把AI补丁当成最终答案。

一个能编译、能运行、甚至能通过部分测试的补丁，不代表它就是正确的工程修复。还得看：

• 符不符合架构原则
• 符不符合代码规范
• 会不会破坏兼容性
• 符不符合产品设计
• 性能和可维护性如何

更关键的是，安全修复本身可能引入新Bug。所以AI生成补丁适合当起点，不能当终点。

Chubirka团队为了验证误报漏报，做了45小时连续测试，尽管大量使用AI，最后还是需要5个人一起完成。

这再次说明：AI能加快单个环节，但规模化安全能力还是要靠流程设计、专业人员和验证机制。

中国企业别因为有了AI就放松工程标准，必须同步建设代码审查、测试验证和质量保障体系。

一个容易忽略的风险：AI自己也是攻击目标

讨论AI安全时，大家往往只关注\"AI能帮我们找多少漏洞\"，但研究员Garrity提出了一个更大的问题——AI产品和AI基础设施本身正在成为新的攻击目标。

Langflow、Bifrost、MCP Python SDK这些都出过远程代码执行问题。背后更深层的问题是权限管理。

为了让AI Agent干活，企业不断给它接入更多系统：访问Salesforce、控制AWS资源、读取内部信息、调用业务流程。从功能角度看这是必须的，但从安全角度看，这等于造了一个权限越来越高、边界越来越宽的新型软件主体。

Garrity的警告很直接：在一些组织里，传统安全一直强调的最小权限原则，在AI项目推进中几乎被扔到一边了。

这对中国企业是个严重警示。如果一个AI Agent既能读敏感数据、又能操作云资源、还能调用业务系统，那它自己就是高价值目标。攻击者不用直接打核心系统，只要搞定这个Agent，或者利用它的框架、插件、SDK里的漏洞，就能打开通往更多内部资源的大门。

所以AI安全建设不能只问\"模型会不会输出错答案\"，对真正进生产环境的Agent系统，必须重新审视经典安全原则：

• 它有什么权限？
• 这些权限是否超过必需范围？
• 它能访问什么数据？
• 它能调用什么工具？
• 出问题能不能快速撤权？
• AI基础设施自己有没有进漏洞管理范围？

这些问题不新鲜，新的问题是：企业正在以远高于传统基础设施的速度，把AI连到越来越多关键系统上。安全治理跟不跟得上，正在成为新的风险边界。

给中国企业的七条实践建议

综合Glasswing、curl和Red Hat的案例，结合中国企业的实际情况，这里有七条实用建议：

1) 把发现和判断分开

AI发现的数量≠真正要修的漏洞数量。扫描结果只是输入，真正的优先级要结合可利用性、部署环境、软件语境和维护者判断。建立独立的风险评估环节，别被海量发现淹没。

2) 保留和强化人工分诊

Glasswing证明了，AI发现能力提升后，人工分诊会成为新瓶颈。这不该绕开，反而要重点设计和优化。引入AI工具的同时，必须同步投资安全专家培养和分诊流程优化。

3) 让懂系统的人参与Agent建设

缺少领域专家设计Agent技能，很容易产生大量噪声。不能只问\"用什么模型\"，还要问\"谁在教模型干这活儿\"。应该组建安全专家和AI工程师的混合团队。

4) 让确定性工具和AI协同，别互相替代

Red Hat的经验表明，AI可以和现有扫描器、代码分析工具、工作流引擎一起用。确定性工具提供稳定证据，AI负责聚合关联，人类负责最终判断。别扔掉已有的安全工具投资，构建混合架构。

5) 把AI补丁当候选，不是最终答案

60%能直接用说明潜力大，但40%有问题也说明代码审查、测试、架构验证不能省。在自动修复流程里强制加入人工审核关卡。

6) 建立持续化的VulnOps

AI每天都能产生大量发现时，传统的按季度、按项目集中处理漏洞的方法维持不下去了。发现、分诊、验证、修复、测试必须转向连续运行。把漏洞管理纳入DevOps流水线，实现安全左移和持续响应。

7) 把AI系统自己纳入攻击面管理

别忘了AI本身也是新攻击面。对AI Agent实施严格的权限管理、访问控制和审计机制，确保AI基础设施符合企业安全基线，定期做安全评估。

最后想说的

Glasswing五个月的实践，真正展示的不是\"AI能自动找到大量漏洞\"——这已经不新鲜了。它真正有价值的地方，是把AI漏洞管理大规模落地后的一系列现实问题提前摆了出来。

当漏洞发现变便宜，验证变贵了。当安全结果变丰富，注意力变稀缺了。当自动修复成为可能，测试和工程审查变得更重要了。当AI获得越来越多权限，AI自己又成了新的安全边界。

所谓的\"漏洞末日\"并没有按想象的方式发生。AI没有一夜之间把世界淹没在零日漏洞里。至少从Glasswing的早期数据看，大量AI发现还没转化成真实世界的大规模利用。

真正先到的，是另一种压力：安全团队需要处理比过去多得多的发现，却还是只能靠有限的人类专家做最终判断。

所以中国企业接下来真正要建设的，不只是更强的AI漏洞发现能力，而是与这种发现能力相匹配的漏洞运营体系：

• 机器负责规模
• 专家负责判断
• 工具负责证据
• 流程负责质量
• 权限体系限制AI自己的攻击面

这才是AI时代漏洞管理要建立的新平衡。

Glasswing的实践告诉我们，AI没有让人退出安全流程，它只是让\"人应该出现在哪里\"变得比过去更重要。能率先建立起\"AI+人类专家\"协同机制、构建起持续化漏洞运营体系、并把AI自身纳入安全治理的企业，才能真正把AI的发现能力转化成实际的防护能力，在新一轮技术变革中占据主动。

相关阅读

你的AI代理删了生产库，保险却说\"不赔\"？网安人必看的5个理赔暗坑

AI吹得再响也没用！评估Agentic SOC的10大维度，一线SOC分析师亲测指南

CISA停更漏洞周报背后：漏洞管理从“看CVSS分数”转向“看真实风险”，一线团队如何落地？

联系我们

合作电话：18610811242

合作微信：aqniu001

联系邮箱：[email protected]