别再恐慌了：一份给工程师的AI漏洞发现与修复务实指南

——当模型能在午餐前挖出上百个漏洞，真正的瓶颈已经不是“找”，而是“怎么办”

故事要从一个差点闯祸的Agent说起。（虚构故事，如有雷同，纯属巧合）

团队用AI Coding助手生成了一个订单服务的支付回调接口。代码看起来挺像样，SQL查询、异常处理、日志记录，该有的都有。李雷是那种有十几年经验的资深工程师，扫了一眼代码，看到try-catch把异常兜住了，又确认了请求签名校验，就合并了。毕竟，AI写的代码嘛，人审核一下就行。

三个月后，团队把混沌工程纳入了测试流程。他们模拟了一个极端的支付回调场景——攻击者伪造了一个看似合法的回调请求，但在JSON深层嵌套了一个类型混淆的字段。结果，这个字段越过了所有校验，直抵数据库。李雷看着屏幕上那个不该出现的SELECT结果，后背发凉。

问题出在哪里？不是签名校验没做，不是try-catch没写。而是那个try-catch里只catch了三种特定异常，第四种悄悄溜走了——AI生成代码时，注意力刚好用完在那个上下文窗口的边缘。而韩梅梅审核的时候，也用一种经验主义的“有try-catch就行”放过了它。人在注意力不足时，和AI犯的错误如出一辙。

但故事还没结束。一周后，李雷用了本文的方法，借助Agent重新扫描了整个代码仓库，不仅找到了这个漏洞，还自动生成了修复补丁。他没有安全研究员的背景，只靠合适的提示词和一套工程化流程，就把团队从焦虑中拽了出来。

这就是我们今天要聊的：AI驱动的漏洞发现与修复循环，以及为什么你不需要恐慌，也不需要成为安全专家。

一、威胁模型：你的安全边界，不是模型猜出来的

很多团队第一次用AI做安全扫描，经历都惊人的相似：模型一口气报了200个“高危漏洞”，工程团队花了两周排查，发现其中180个是误报。剩下的20个里，15个虽然“技术上可利用”，但在实际部署环境中，外面有认证网关挡着，配置文件是受信来源，攻击者根本摸不到。真正需要修的，只有5个。

模型错了吗？不，模型判断代码的能力很强。它错在没有理解你的上下文。

一个安全团队说得非常精辟：“模型对代码有很好的上下文理解，但对我们的上下文理解不足。”另一位验证了这一判断：当他们为模型提供了清晰文档化的威胁模型后，模型的发现“在90%的情况下是可利用的”。对比没有威胁模型时40%的误报率，这不是微调，这是质变。

别再让模型猜你的边界

威胁模型的作用，是在一切开始之前，明确回答四个问题——这就是经典的Shostack四问：我们正在构建什么？可能会出什么问题？我们正在对此做什么？我们做好了吗？

怎么建？两步走。

第一步，把给新入职安全工程师的“第一天资料包”喂给模型：架构文档、Wiki、入口点说明、Git提交历史、过往CVE记录。让模型读完后，产出一份威胁模型草稿，包括系统上下文、关键资产、入口点、信任边界，以及明确写出你不关心哪类漏洞。

为什么“不关心什么”和“关心什么”同等重要？看一个真实案例。一个团队审查了数百个历史CVE和安全修复提交，提炼成“漏洞形态”提示丢给模型。他们不要求模型漫无边际地找漏洞，而是追问两个具体问题：“这个修复是否完整？同样的修复是否被应用到所有其他地方？”一小时内，他们发现了三个可利用的漏洞。这个团队总结得很妙：“‘人们过去利用过什么’有时是比‘在这个代码库里帮我找漏洞’更容易的制胜秘籍。”

第二步，让模型访谈最了解系统的那个人。有了第一步