发现漏洞很容易，难的是让人去修——Anthropic 的 1596 个漏洞告诉我们什么

Anthropic 发了篇博客，讲他们怎么用 Claude Opus 做代码安全。文章很克制，没有”革命性突破”这种词，就是老老实实讲方法论：威胁模型、沙箱、发现、验证、分类、修补，六步循环。

我读完之后，脑子里一直转的不是那六步流程，而是一个数字：1596。

这是 Anthropic 截至 5 月 22 日披露的开源软件漏洞数量。其中有多少被修复了？97 个。6%。

这个比例比任何技术细节都重要。它指向一个问题：当我们有了能大规模发现漏洞的工具，为什么漏洞还是没人修？

发现漏洞已经不值钱了

文章里有句话很关键：“discovery is now straightforward to parallelize, and the bottleneck has shifted to verification, triage, and patching。”

翻译过来就是：发现漏洞这事现在可以并行化了，真正的瓶颈是验证、分类和修补。

这和我之前的直觉相反。我一直以为找到漏洞是最难的部分——你得理解代码逻辑、数据流、信任边界，还得有创造性思维去想”攻击者会怎么用这个”。但现在 Anthropic 告诉你，这事可以让模型并行去做，给个威胁模型，分几个搜索空间，几个 agent 同时跑，漏洞就出来了。

文章里有个例子：一个团队把过去几百个 CVE 翻出来，提炼成”bug 形状”的提示词，然后问模型两件事——修复完整吗？其他地方也应用了吗？一个小时找到 3 个可利用的漏洞。

一个小时。3 个可利用的漏洞。

这就是现在的效率。发现不再是瓶颈。

那瓶颈是什么？是人。是那些收到漏洞报告的维护者，是那些需要判断”这个漏洞到底要不要修”的工程师，是那些得写补丁、测试、发布的开发者。

1596 个漏洞，97 个修复。剩下的 1499 个，要么没人看，要么看了觉得不重要，要么觉得太麻烦不想修，要么修了但没发布。

这不是技术问题，这是人的问题。

威胁模型：让 AI 知道什么算漏洞

文章里有个出人意料的发现：大多数误报不是因为模型看不懂代码，而是模型不理解你的信任边界。

举个例子：模型可能把某个配置文件的读取标记为漏洞，因为在它的认知里，配置文件可能被攻击者控制。但在你的系统里，配置文件只有 root 能改，这就是个误报。

反过来，模型可能认为某个面向互联网的服务是内部服务，从而漏报真正的漏洞。

一个团队的经验是：当威胁模型定义清晰时，模型发现的漏洞”90% 的时间都是可利用的”。

90%。这个数字很吓人。它意味着，如果你能把威胁模型讲清楚，AI 的安全审计能力已经接近人类安全研究员了。

那怎么讲清楚？文章给的方法很实在：先从代码、文档、历史漏洞里提取信息，让模型生成一个威胁模型草稿，然后让模型去访谈一个真正了解系统的人。用 Shostack 的四个问题：我们在构建什么？什么可能出错？我们在做什么应对？我们做得好吗？

最后，把这个威胁模型保存成 THREAT_MODEL.md，放在代码仓库里。

这个细节很有意思。它把威胁模型从”安全团队脑子里的东西”变成了”代码仓库里的文档”。这意味着：

1. 新来的工程师能看懂系统的信任边界
2. AI 在扫描时能读取这个文档，知道什么该关注什么该忽略
3. 威胁模型会随着代码更新而更新，而不是写在某个没人看的 wiki 里

如果威胁模型这么重要，为什么以前没人这么做？

答案可能是：以前写威胁模型的成本太高了。你得找安全专家，得开会讨论，得画架构图，得写文档。现在你可以让 AI 先生成一个草稿，然后人类去修正。成本降下来了，这事才变得可行。

发现的反直觉：别告诉 AI 怎么扫描

文章里有个让我意外的发现：更详细的 prompt 反而让发现阶段的效果变差。

原文是这么说的：“Counterintuitively, more prescriptive prompts make discovery worse—long checklists tend to reduce the model’s creativity and generate fewer novel bugs.”

换句话说，规定得越死，模型找到的漏洞就越少。长清单会压制模型的创造性。

这和我之前写 prompt 的经验完全相反。我一直觉得 prompt 越详细越好，越具体越好，最好把每一步都列出来。但 Anthropic 说，对于发现漏洞这种需要创造性的任务，你应该只给目标和上下文，让模型自己决定怎么扫描。

文章给的建议是：

• 提供目标和上下文：为什么要扫描，什么样的发现是有意义的，扫描的是什么系统
• 把”如何扫描漏洞”留给模型自己决定
• 可以要求模型关注特定类型的漏洞（比如基于历史 CVE 的模式）
• 让模型自己决定需要什么工具，甚至让它自己写工具

这个观察可以推广到其他领域。写文章、做设计、想方案——给太多规定反而会限制输出。给目标、给上下文、给约束条件，但把”怎么做”留给执行者。

文章里还有个细节：有个渗透测试团队给了 agent 发送请求、检查响应、查询流量日志的工具。结果 agent 不需要猜测路径是否可达，可以边扫描边测试，误报率降到接近零。

这说明什么？工具比 prompt 重要。给模型合适的工具，比给模型详细的指令更有效。

验证：让另一个 AI 来挑刺

这是文章里我最喜欢的部分：验证应该由独立的 agent 来做，而且这个 agent 的任务是”证伪”发现。

文章的逻辑是这样的：发现阶段优化的是召回率（recall），也就是尽可能多地找到漏洞，哪怕有些是误报。验证阶段优化的是精确率（precision），也就是排除那些不可利用的发现。

如果让同一个 agent 同时做这两件事，它会自我审查，把一些真正的漏洞也过滤掉。Anthropic 吃过这个亏：让发现 agent 同时验证，结果漏掉了真正可利用的漏洞。

所以他们把验证拆出来，让独立的 agent 来做。关键细节：

1. 验证 agent 和发现 agent 不能共享上下文，要在独立的容器里运行
2. 只给验证 agent 两样东西：发现的描述（或 PoC）和代码库
3. 提示验证 agent “假设每个发现都是误报，去找理由证明它是错的”

这个”假设是误报，去找理由证伪”的思路很妙。它把验证变成了一个对抗性任务，而不是确认性任务。

结果呢？添加对抗性验证器把不可利用的发现减少了一半。要求 PoC 确认把误报率降到接近零。

这种对抗性验证是个通用模式。对抗训练提高模型鲁棒性，控辩双方确保法律公正，同行评审挑战科学假设。现在在安全审计里，我们有两个 AI agent，一个找漏洞，一个证伪漏洞。这不是简单的”检查两遍”，而是结构性的对抗。

文章里还提到，如果单个验证 agent 还是放过太多误报，可以跑多个独立的验证 agent，用不同的角度或不同的模型，然后取多数投票。这其实就是 ensemble 的思路，只不过应用在了安全审计上。

分类：从 100 个发现到 10 个行动

发现阶段可以并行，一个小时找出 100 个漏洞候选。但接下来呢？你得判断哪些值得修，哪些可以忽略。

这就是分类（triage）阶段，文章说它已经成了瓶颈。

分类的任务是：

1. 去重：同一个漏洞可能在多个调用点被发现，或者同一个根本原因表现出多个症状
2. 评级：基于可达性、攻击者控制程度、前置条件、认证要求、读 vs 写、影响范围

文章给了一个评级框架：

• 零前置条件 + 未认证远程访问 = 严重或高
• 一两个前置条件，或需要认证 = 中
• 三个以上前置条件，或仅本地 = 低

但更重要的是这个细节：让模型在评级之前先把每个问题的证据写出来。这样可以防止模型锚定在漏洞类别上（“SQL 注入，所以是严重”），然后根据类别来调整严重性。

这是个好习惯，不只是对 AI，对人类也一样。先写证据，再下结论。先列事实，再判断严重性。

文章里还提到一个实际问题：如果给工程师发一堆发现，其中大多数是不可利用的，他们会失去信任，不再看报告。这就是为什么验证和分类这么重要——它们保护了下游工程师的注意力。

这其实就是信号噪声比的问题。发现阶段产生大量信号（包括噪声），验证阶段过滤噪声，分类阶段排序信号，修补阶段处理排序后的信号。每个阶段都在提高信噪比。

6% 的修复率：开源维护的困境

回到开头那个数字：1596 个漏洞，97 个修复，6%。

这个比例说明了什么？

首先，它说明发现漏洞的成本已经远低于修复漏洞的成本。以前是”找不到漏洞”，现在是”找到了但没人修”。

其次，它说明开源维护的系统性困境。很多开源项目的维护者是志愿者，他们有自己的本职工作，修漏洞是额外负担。收到一个漏洞报告，他们得：

1. 理解漏洞
2. 判断严重性
3. 写补丁
4. 测试补丁
5. 发布新版本
6. 写安全公告

这每一步都需要时间。如果一天收到 10 个漏洞报告，每个都要走这个流程，维护者根本忙不过来。

文章里提到一个解决方案：让 AI 帮忙写补丁，然后人类审查。这可以降低修补的成本，但问题是：人类还是得审查。AI 写的补丁可能有 bug，可能破坏了其他功能，可能引入了新的漏洞。

文章给了一个验证阶梯：

1. 构建：补丁能编译，新测试通过
2. 复现：原始 PoC 不再工作
3. 回归：原始测试套件仍然通过
4. 再攻击：新的发现 agent 跑对抗性检查

这个阶梯设计得很好，从便宜到贵，从简单到复杂。但它还是需要人来执行，或者至少来监督。

所以 6% 的修复率可能短期内不会显著提高，除非：

1. 维护者有更多时间（不太可能）
2. 有更多人参与维护（需要社区建设）
3. 修补流程进一步自动化（AI 写补丁 + 自动测试 + 自动发布）
4. 漏洞报告更精准（减少无效报告，提高信噪比）

Anthropic 的方法在第四点上有贡献——通过验证和分类，减少无效报告。但它没有解决前三点。

这引出一个更大的问题：AI 工具在提高效率的同时，是否也在加剧某些系统性问题？

Veracode 的报告显示 45% 的 AI 生成代码有漏洞。AI 可以快速生成代码，但也引入了更多漏洞。AI 可以快速发现漏洞，但也给维护者带来了更多报告。效率提高了，但工作量也增加了。净效果是什么？

市场反应：安全行业的 disruption？

文章没提，但背景调研里有个有意思的细节：Claude Security 发布当天，网络安全股票大跌。JFrog 跌了近 25%，CrowdStrike、Datadog、Zscaler 跌了约 11%，Fortinet 和 Okta 跌了约 6%。

市场认为 AI 驱动的代码分析可能会颠覆传统安全工具。

但我有点怀疑这个判断。传统 SAST 工具（静态应用安全测试）确实可能被替代，因为它们本质上是模式匹配，而 AI 可以做更复杂的推理。但安全行业不只是 SAST，还有 DAST（动态测试）、IAST（交互式测试）、RASP（运行时保护）、SIEM（安全信息和事件管理）等等。

AI 可能在某些环节（比如代码审查、漏洞发现）有优势，但在其他环节（比如运行时保护、事件响应）还需要传统工具。

更可能的是：AI 会和传统工具结合，而不是替代。比如，用 AI 来分类 SAST 的发现，用 AI 来写补丁，用 AI 来做对抗性验证。

CSIS 的分析文章也提到了 Claude Security 的局限性：它只在源代码分析阶段工作，无法判断漏洞在生产环境中是否可利用。安全故障往往来自系统配置、认证流程、基础设施依赖、用户行为——这些源代码分析工具看不到。

所以市场反应可能是过度了。但这也说明：投资者认为 AI 在安全领域有巨大潜力，哪怕现在的工具还不完美。

我的看法

这篇文章最有价值的不是那六步流程——那其实是安全团队已经在做的事，只是形式化了。最有价值的是几个令人意外的洞察：

1. 发现漏洞已经不值钱了。这和我之前的认知相反。我一直以为找到漏洞是最难的部分，但现在发现，验证、分类、修补才是真正的瓶颈。

2. 更详细的 prompt 反而让发现效果变差。这对所有用 AI 做创造性任务的人都是个提醒：给目标、给上下文，但别规定太多细节。

3. 对抗性验证是个通用模式。让一个 AI 找问题，让另一个 AI 证伪问题。这不仅适用于安全审计，也适用于代码审查、产品设计、决策分析。

4. 6% 的修复率揭示了开源维护的困境。技术进步了，但人的问题没解决。这可能是 AI 安全工具面临的最大挑战。

5. 威胁模型应该代码化。把 THREAT_MODEL.md 放在代码仓库里，让 AI 和人类都能读取。这个细节很实用，也很深刻。

文章最后说：

“We believe it’s getting easier for models to find and exploit vulnerabilities in code. Thus, our work as defenders is to find and fix the vulnerabilities in our code before adversaries exploit them.”

我们相信模型发现和利用代码中的漏洞会越来越容易。因此，我们作为防御者的工作是：在对手利用漏洞之前，找到并修复我们代码中的漏洞。

这句话很对，但也很乐观。现实是：找到漏洞容易，修复漏洞难。1596 个漏洞，97 个修复。6%。

这不是技术能解决的问题。这是人的问题。

你们团队怎么处理安全漏洞报告？有没有遇到过”漏洞太多修不过来”的情况？欢迎分享你们的经验。

原文参考

Using LLMs to secure source code — Eugene Yan, Henna Dattani et al. Anthropic Blog, May 27, 2026 https://claude.com/blog/using-llms-to-secure-source-code