以防大家不知道，Anthropic开源了自己的漏洞挖掘Harness

以防大家不知道，Anthropic开源了自己的漏洞挖掘Harness 关注 以防大家不知道，Anthropic开源了自己的漏洞挖掘Harness 2026-06-14 16:36:07 漏洞发现，已经不是最难的环节 Anthropic在和安全团队合作的过程中，总结出一个判断： 发现漏洞，正在变得容易；证明它是真的、决定先修哪个、把它修对，才是新瓶颈。 这和传统安全工程很不一样。 以前，一个高级安全工程师可能要花几天甚至几周，在代码仓库里逐层追踪输入、权限、调用链、异常处理、依赖关系。 现在，AI可以同时派出多个 Agent，对不同模块、不同攻击面、不同漏洞类型展开扫描。 但这也带来了新问题：AI一上午能扔出上百个疑似漏洞，工程团队却不可能照单全收。 安全工作的负担，从「找不到漏洞」变成了「漏洞太多了，怎么判断」。 六步闭环：AI安全扫描不能只会发现漏洞 Anthropic把效果最好的团队实践，压缩成了5步： 威胁模型 ：先说清楚什么算漏洞。 漏洞发现 ：让AI读代码、看文档、提出候选问题。 独立验证 ：用另一个 Agent 反向证明它是不是误报。 分类定级 ：去重、排序、判断修复优先级。 补丁修复：写测试、打补丁、复测、再攻击。 最关键的是： 发现不是终点，只是流水线的入口。 如果一个团队只让AI扫描，然后把原始结果丢给业务，基本很快就会翻车。 因为业务团队看到一堆误报、重复、严重性夸大的报告后，会失去对安全团队的信任。 没有验证和分级的发现，只是在给业务制造噪音。 先告诉AI「什么才算真的危险」 最常见的误报，并 不是AI不懂代码，而是AI不懂你的系统 。 比如，AI看到一个配置文件能影响SQL语句，立刻报SQL注入。 但在这个系统里，配置文件只由管理员维护，不属于攻击者可控输入。 那这就未必是漏洞。 反过来，AI也可能把一个暴露在公网的服务，当成内部服务，从而漏报真正危险的问题。 所以第一步不是开扫，而是建立 威胁模型 。 威胁模型要回答几个问题： 系统在做什么？ 重要资产是什么？ 入口在哪里？ 哪些输入可信，哪些输入不可信？ 哪些漏洞类型我们关心，哪些不在范围内？ 过去出现过什么漏洞？ 有团队发现，当系统设计文档、约束、历史漏洞和威胁边界都写清楚时，AI给出的发现中，可利用比例能达到90%。 AI不是万能的安全专家，它更像一个读得很快、能推理、能写脚本的工程师。 你不给它上下文，它就只能按常见的互联网假设来判断风险。 安全风险也要取决于部署方式、权限边界、WAF、租户隔离等进行判断。 AI 虽然有代码上下文，但未必有组织上下文。 沙箱不是摆设，是AI安全的保险 让 Agent 自主跑代码、写PoC、发请求，听起来很诱人，也很危险。 有团队告诉AI「你没有网络」，但实际没限制，结果AI自己发现还能从GitHub拉东西。 还有团队观察到，Agent 在扫描过程中顺手回复了一个GitHub issue。 这不是恶意行为，但说明了： 约束不能靠提示词，必须靠系统配置。 Anthropic建议，发现阶段读代码可以用容器； 但运行目标程序、执行PoC，最好放在更强隔离的微虚拟机或完整虚拟机里，并严格关掉对生产环境的出口。更重要的是，永远不要把这些东西暴露给 Agent： ~/.aws 、 ~/.ssh``.env 、生产凭据 、内网敏感服务访问权限 正确做法是：先联网搭环境，拉依赖、构建、跑测试； 然后做快照，断网，只允许访问模型API，并且最好通过本地代理转发。 每次扫描，都从同一个干净快照开始。 这样做有两个目的： 一，保护真实系统。二，证明漏洞真的可利用。 静态分析只能提出假设。 沙箱里的PoC，才能告诉你：这个路径是否可达？上游有没有校验？认证网关有没有挡住？依赖版本是不是一致？ 有安全团队说：给 AI测试、真实运行环境、PoC执行能力，是提升效果最大的杠杆之一。 漏洞发现阶段要「少管一点」 很反直觉：提示词越长，漏洞发现效果未必越好。 Anthropic观察到，AI在漏洞发现阶段，往往更适合简单明确的目标，而不是检查清单。 原因也不难理解。 过度规定扫描方式，会让AI只按清单找已知类型，反而降低发现新问题的创造性。 更好的方式是告诉AI： 为什么扫描？ 什么样的问题算重要？ 系统的威胁边界是什么？ 输出报告要包含哪些字段？ 至于怎么找，让AI自己决定。 当然，如果团队想专门找某类漏洞，比如路径穿越、反序列化、命令注入、权限绕过，也可以指定漏洞类型，并解释这种漏洞一般长什么样、常出现在哪里。 工具也很重要。不要只给AI一段代码。 要给它搜索、读取、运行测试、调用安全工具、写小脚本的能力。 现在的AI已经越来越擅长为自己写工具。 多个 Agent 如果都盯着同一批浅层问题，最后得到的是一堆重复报告。 验证 Agent 必须「唱反调」 发现 Agent 的目标是高召回：宁可多报，也别漏掉。 验证 Agent 的目标是高精度：宁可严格，也别把不可利用问题送到工程团队面前。 这两件事，不能混在一起做！ 如果让同一个 Agent 一边发现、一边验证，可能会把真实漏洞也过滤掉。 Anthropic的经验是， 把验证拆成独立步骤，效果更好 。 验证 Agent 应该在全新的容器中运行，不能共享发现 Agent 的文件系统和对话历史。 它只拿到两样东西： 漏洞报告或PoC 代码仓库 然后它的任务不是「证明漏洞成立」，而是 假设这是误报，尽力推翻它 。 这种「对抗式验证」非常关键。根据Anthropic的经验，加入一个专门唱反调的验证 Agent 后，不可利用发现大约能减少一半。如果再要求验证 Agent 构建并运行PoC，误报率可以接近归零。 AI找洞，也要用AI反驳AI。 漏洞分类也很重要 当模型可以半天找出一百个候选漏洞后，分类定级就变成了核心战场。 分类至少要解决三件事： 哪些报告是重复的？ 哪些是真正高危？ 哪些应该先修？ 重要是看漏洞本质，而不是看漏洞表面。 同一个缺失鉴权，可能在十几个路径都被报出来；同一个输入校验问题，可能在多个调用点表现不同；一个漏洞的原因和后果，也可能被拆成两条报告。 因此，去重不能只按文件名，还要按根因、漏洞类别、数据流和修复方式判断。 严重性评估也不能只看漏洞名。 「SQL注入」听起来很吓人，但如果只能由管理员配置触发，未必是紧急问题。相反，一个看似普通的路径处理错误，如果无需登录、公网可达、能读全租户数据，就可能是高危。 Anthropic建议从这些维度评估： 攻击者是否能从真实入口到达？ 输入是否由攻击者控制？ 触发漏洞需要多少前置条件？ 是否需要登录或管理员权限？ 只能读数据，还是能写入和修改？ 影响一个用户、一个租户，还是整个平台？ AI在打分前，应该先逐项写出证据，再给严重性。 否则它很容易被漏洞类型锚定，看到「注入」就评为高危。 补丁必须经得起「再攻击」 修复不是让AI改几行代码就完了。 正确流程是：先写一个能复现漏洞的失败测试；再打补丁；然后确认测试通过；再跑原有测试；最后让新的发现 Agent 重新攻击补丁。 这其实就是安全版的测试驱动开发。 因为生成补丁有几个常见失败情况： 只修了一个调用点，根因还在。 补丁过度严格，影响了正常业务。 删除了依赖