用 LLM 保护源代码：Claude Opus 漏洞发现与修复完整指南

模型能力在快速但不均衡地进步。我们与安全团队合作，在他们的代码和开源软件中发现和修复漏洞，从中更好地理解了如何用模型保护源代码。核心发现：发现漏洞已易于并行化，瓶颈已转移到验证、分类和修补。

作为参考，截至 2026 年 5 月 22 日，我们在开源软件扫描中披露了 1,596 个漏洞，其中 97 个已被修复。

本文将介绍如何与 Claude Opus 协作，构建威胁模型、发现代码库中的漏洞，然后验证、分类和修补它们。

发现-修复循环

高效的团队都收敛于以下六步循环：

1. 威胁建模：扫描前先定义什么是漏洞
2. 沙盒：构建隔离环境以安全运行 Agent 和验证利用
3. 发现：让模型搜索源代码中的漏洞
4. 验证：独立确认哪些发现是真正可利用的
5. 分类：去重、评估严重性、确定优先级
6. 修补：应用修复、确认漏洞消除、搜索变体

前两步（威胁建模和沙盒）是一次性投入，后续四步构成循环。首次扫描发现最多，后续递减但不会归零——模型是随机的，大型代码库有长尾漏洞。

1. 威胁建模：定义什么是漏洞

假阳性最常见的原因是模型不了解你的信任边界。

分两步构建威胁模型：

第一步：从代码、文档和漏洞历史引导。 向模型提供架构文档、wiki、入口点、git 历史和过去的漏洞。让模型创建包含系统上下文、资产、入口点和信任边界的威胁模型。

一个团队审查了数百个历史 CVE 和安全修复提交，提炼成"漏洞模式"提示，问模型两个问题：修复完整吗？是否已应用到所有地方？一小时内发现三个可利用漏洞。"人们过去利用过什么"有时比"帮我找这个代码库的漏洞"更容易成功。

第二步：让模型采访了解系统的人。 用 Shostack 的四个问题：我们在构建什么？可能出什么问题？我们在做什么来防范？我们做得够好吗？

实用建议：

• 考虑依赖项目的安全策略（如 vLLM 的 security.md、SQLite 的防御文档）
• 明确命名什么是可信的——如果你信任配置文件或已认证客户端，记录在威胁模型中
• 在仓库中包含 THREAT_MODEL.md，随代码更新
• 在发现阶段作为范围（分区代码、优先排序目标），在分类阶段作为过滤器

一个团队有 40% 的假阳性率。发现是可复现的，PoC 证明了可利用性。但开发团队认为不符合项目的威胁模型。CISO 的总结："模型对代码有很好的理解，但对我们没有。"

2. 沙盒：安全运行 Agent 并验证可利用性

沙盒有两个目的：保护系统和证明可利用性。

隔离建议：

• 代码阅读用容器即可
• 运行目标和 PoC 用 microVM（如 Firecracker）或完整 VM
• 出站流量锁定，绝不让凭证（~/.aws、~/.ssh、.env）对 Agent 可用

设置流程：

1. 给沙盒网络访问权限，拉取依赖、构建、安装工具、部署目标、运行测试
2. 快照环境，移除网络访问
3. 扫描期间仅允许到模型 API 的流量
4. 每次扫描加载快照，确保从同一干净状态开始

可利用性验证： 静态扫描时模型只能假设什么可能出错，无法测试路径是否可达或有补偿控制。一个进攻性安全团队的经验："最大效能杠杆是给模型测试平台、运行中的系统和可执行的 PoC。"

如果构建代表性沙盒不切实际， 可以从发现步骤（纯源码分析）开始，前沿模型仅分析源码就能有效发现漏洞，但在验证阶段投入更多时间。

3. 发现：提供丰富上下文和简短提示

提示技巧：

• 提供目标和上下文（为什么扫描、什么算重要发现），把"如何扫描"留给模型
• 过于具体的提示反而降低发现效果——长检查清单会限制模型创造力
• 可以要求特定漏洞类别
• 定义结构化输出格式
• 给模型搜索和阅读代码的工具（grep、glob），以及安全专用工具（SAST、fuzzer）
• 让模型自己构建需要的工具

发现流程建议：

1. 让模型先对系统做第一遍分区（按攻击面、端点或组件）
2. 将分区喂给并行发现 Agent，避免收敛到相同浅层漏洞
3. 最后运行系统级扫描，以分区级发现为上下文

一个团队尝试暴力水平扩展，效果递减。另一个增加了更多关注区域和并行 Agent，得到"大量问题"，但大部分是重复的。

如果有沙盒，让发现 Agent 为每个发现构建 PoC（脚本、崩溃输入或失败测试）。PoC 帮助 Agent 迭代定位发现，并为验证 Agent 提供具体证据。

4. 验证：过滤不可利用的发现

关键原则：发现优化召回率，验证优化精确率。 让同一个 Agent 同时做发现和验证会导致自我审查，过滤掉可利用的真阳性。

验证 Agent 必须独立于发现 Agent：

• 在全新容器中运行，不共享文件系统或对话历史
• 只给验证 Agent：(1) PoC 或书面发现，和 (2) 代码库
• 如果暴露于发现 Agent 的推理过程，它可能只是同意而非测试

提示验证 Agent 反驳发现 Agent 的结论。 假设每个发现是假阳性，搜索其为错的理由。

效果数据：

• 添加对抗性验证器，不可利用发现率减半
• 要求验证器也构建确认利用的 PoC，假阳性率降至接近零

如果一个验证 pass 仍放过太多不可利用发现，尝试运行多个独立验证器（不同角度或不同模型），取多数票。

5. 分类：按根因去重，按前置条件和影响排序

分类评估修补优先级。随着模型发现漏洞能力的增强，分类已成为瓶颈。

避免告警疲劳： 如果提交的漏洞大部分是重复或严重性虚高，产品工程师可能停止阅读，包括真正需要紧急修补的。

去重方法：

1. 先用廉价确定性 pass：相同文件、相同类别、漏洞行号在 10 行以内
2. 再用模型应用定性规则

去重规则：

严重性评估维度：

严重性分级起点：

• 零前置条件 + 未认证远程访问 → 严重或高危
• 1-2 个前置条件或需要认证 → 中危
• 3+ 个前置条件或仅限本地 → 低危

模型可能虚报严重性，因为它不了解攻击者实际控制什么输入，或看不到补偿控制。解决方案是在分类时提供威胁模型。

6. 修补：闭环并改进下一轮的上下文

修补是关闭循环的地方。它还能基于已验证发现改进威胁模型。

修补前： 先写一个在现有代码下失败的测试。然后实现修复，确认测试通过且不破坏其他功能。这是测试驱动开发。

一个渗透测试者发现生成的补丁质量不一致——直到工具告诉模型通过在修补代码上重新运行 PoC 来验证补丁。通过给模型反馈来迭代，补丁质量大幅提升。

修补建议：

• 让模型识别并修复根因，而非仅修复特定调用点
• 搜索变体：(1) 同模式（其他调用点）(2) 同类（一个 SQL 注入意味着更多 SQL 注入）
• 用新发现更新威胁模型
• 发货前运行对抗性检查：让新发现 Agent 以攻击者身份探测补丁
• 要求最小化补丁——不重构、不顺便清理、不重新格式化

一个团队最常见的补丁失败： "建议的补丁尽可能严格，甚至会断开与其他服务的连接。虽然解决了问题，但也破坏了依赖关系。"

补丁验证阶梯：

1. 构建：补丁编译且新测试通过
2. 尝试复现：原始 PoC 停止工作
3. 回归检查：原始测试套件仍然通过
4. 重新攻击：新的发现 Agent 做对抗性检查

如何开始

克隆 defending-code-reference-harness 并在 Claude Code 中运行 /quickstart。它会在演示目标上引导你完成从威胁建模到扫描到分类的交互式工作流。

然后在你自己的代码上运行：选择一个服务或包，从代码和文档引导威胁模型，投资构建沙盒，扫描，用独立 Agent 验证，按你的标准分类，修补高危及以上，然后定期重新扫描。

第一次扫描会发现比你预期更多的漏洞。大部分需要验证和分类。在预算更多扫描之前，先预算扫描后的处理流程。

参考资源

• Claude Security：Anthropic 的托管式 Agent 漏洞检测和修补产品
• defending-code-reference-harness：配套仓库，包含交互式工作流 Skills 和自动扫描 demo
• claude-code-security-review action：GitHub Action，在每次 PR 上用 Claude 做安全审查
• Threat Intelligence Enrichment Agent：构建威胁情报丰富 Agent 的 Cookbook
• Vulnerability Detection Agent：构建威胁模型、扫描漏洞、分类发现的 Agent Cookbook

本文翻译自 Anthropic 官方博客，作者 Eugene Yan 和 Henna Dattani。