orchestrating-vulnerability-research

编排漏洞研究

一个 Agent 盯着一个目标，容易自圆其说。它找到一条“可能可利用”的路径，写下一段信心十足的文字，再把自己的文字评为漏洞发现。这段文字不是漏洞。这个技能就是用来避免这种情况的脚手架：为狩猎设定一个无法靠花言巧语绕过的门槛，将目标拆分成多个部分并行处理，而且绝不让构建候选项的 Agent 来判定它是否属实。

这是一个循环，不是一次性流程。持续运行，直到漏洞发现得到证实，或目标确实已被穷尽，而不是在出现第一份看似可信的报告时就停止。

适用场景

• 接到任务，要在整个代码库、二进制文件或指定的在线目标中发现此前未知的漏洞，并且可以调度多个 Agent
• 开展漏洞悬赏或研究活动，深度和新颖性比一次性覆盖报告更重要
• 一次审计或测试已经停滞，或只产生了未经证实的“可能”漏洞，希望由独立评审者来推翻或确认这些猜测
• 具备并行扩展和迭代的预算，并希望在整个工作中落实构建者与评审者分离、以及必须展示触发方式的门槛

不适用场景

• 对源码树进行一次聚焦的覆盖审查（客户端审计、单次检查、交付覆盖情况表）——直接使用 auditing-code-for-vulnerabilities；此技能会调度它，而不是取代它
• 逆向分析或分诊单个二进制文件——使用 analyzing-binaries
• 对单个 Web 应用或 API 进行系统性的黑盒测试——使用 testing-web-applications 或 testing-apis
• 整理已确认的漏洞发现——使用 reporting-security-findings
• 跟踪研究活动的证据、来源和无效线索——使用 maintaining-engagement-state；此技能会生成这份记录，但不规定其格式
• 搜寻他人已经植入的 Webshell 或后门（而非潜在漏洞）——使用 hunting-web-backdoors
• 无状态的抽查——“这个函数是否存在注入漏洞？”只需调用一次构建者 Agent，并不算研究活动。只有规模足够大时，脚手架的额外开销才值得。

循环

五种角色，在目标的每个切片上循环执行。负责人从不进行狩猎，也不做评级；只负责拆解、调度和协调。

decompose → build → critique → iterate → smooth
   lead      hunter   critic     hunter    lead

1. 拆解——划分为最小的、可独立狩猎的切片

负责人将目标拆分为若干部分，每个部分都可以独立狩猎和评判，互不干扰。好的切片只有一个入口面，且可达范围有界。按最有助于确保各部分相互独立的维度拆分：

目标	按以下维度拆分
代码库	入口点（路由／处理程序／消费者），或漏洞类型 × 组件
二进制文件	导出／可达函数簇、解析器或 IPC／RPC 界面
指定的在线目标	主机／服务，再按端点或协议拆分

调度前先写下切片清单。每个切片都要注明：覆盖范围、可达的汇点集合，以及此处的漏洞发现必须达到的门槛（见下文）。切片之间共享状态是一种危险信号——应将它们合并，否则评审者可能因为看到目标的不同部分而意见不一。

2. 构建——每个切片分配一名猎手，只告知目标，不规定方法

为每个切片分配一名全新上下文的构建者 Agent，并指向适用于该产物的领域技能（auditing-code-for-vulnerabilities、analyzing-binaries、testing-web-applications）。向它提供切片、需要保护的资产和门槛——而不是一份操作步骤脚本。告诉它怎么做，它只会照步骤执行并报告成功；告诉它目标和门槛，它就必须真正达到要求。每名猎手都要返回候选项：(位置，漏洞类型，声称的触发方式，已有证据)。

并行运行各个切片；这些切片在设计上彼此独立。每个切片的深度比切片之间的广度更重要——一个已完整触发的漏洞，胜过二十条“可疑”记录。

3. 批判 — 使用独立的批判者，以全新上下文进行反驳

这是整套技能旨在贯彻的规则：构建者绝不评判自己的工作。 每个候选项都交给另一个具有全新上下文的 Agent，由它负责反驳，并检查真实产物——正在运行的二进制文件、实际的 HTTP 响应、已执行的测试、重新阅读过的源代码——而不是猎手对它的总结。

门槛是展示触发效果，批判者只需判断是否达标：

• 代码库：是否存在一个具体输入，能够在攻击者控制不变的情况下到达危险操作，并通过路径上的所有验证器？不能只说“看起来能到达”。
• 二进制文件：在受控输入下是否会崩溃或破坏状态，并且故障原因已弄清楚？不能只说“这个 memcpy 看起来没有边界限制”。
• 在线目标：请求是否可重复地产生异常响应，从而证明存在弱点？不能只说“错误信息暗示了注入”。

如果未达标，批判者应指出候选项与已证实漏洞之间最大的单一差距——缺失的可达性步骤、猎手没有考虑到的验证器，或从未实际运行过的输入。这个差距就是下一轮的工作指令。只说“尚未证实”的批判者是不合格的；它必须说明怎样才能证实或排除问题。

让批判者倾向于反驳。一个经受住真正试图推翻它的 Agent 考验的候选项，价值胜过十个由构建者判定为可利用的候选项。对于高风险候选项，应安排多个持不同视角的批判者（可达性、缓解控制、是否确实能运行），而不是安排三个一模一样的批判者。

4. 迭代 — 根据差距采取行动，循环处理切片

构建者根据批判者指出的差距补全证据：构建可达性步骤，编写真正能触发问题的输入，并考虑验证器。然后将候选项交回批判者。重复此过程，直到满足以下三个停止条件之一：

• 已证实 — 达到门槛，且批判者无法反驳。将其作为一项发现；交给 reporting-security-findings。
• 已排除 — 批判者找到了使问题安全的控制措施，或多轮尝试仍无法触发问题。在评估状态中将其记录为已检查并排除的候选项，并说明原因——已排除的候选项属于覆盖范围记录，能避免你再次搜查同一条路径。
• 预算耗尽 — 已用完该切片的工作额度，问题仍未解决。将其降级为有记录的“疑似，未证实”线索，然后继续；不要为了挽回投入而将其升格为一项发现。

切勿让切片无限循环。循环的失败模式不是过早停止，而是构建者和宽松的批判者来回传递一个未经证实的候选项，直到它听起来像是已证实。

5. 汇总 — 负责人跨切片整合结果

各切片在互不知情的情况下进行搜查；只有负责人能看到所有结果。各切片的循环结束后：

• 去重。 同一个根本原因出现在多个切片中——例如，五条路由都缺少同一个授权层检查，这应是一项有五个实例的发现，而不是五项发现。
• 串联。 一个切片中的薄弱原语，加上另一个切片中可到达的危险操作，往往才构成真正且严重程度更高的漏洞。任何单个猎手都看不到这种组合——这正是负责人发挥作用的地方。
• 对已确认漏洞进行变体排查。 每项已证实的发现都是一个模板；在结束前，对其他切片进行排查，查找相同的错误。
• 核对覆盖范围。 说明哪些切片已按门槛完成搜查，哪些受限于时间，哪些尚未触及。诚实的覆盖范围是交付成果的支柱——参见 reporting-security-findings。

设定判定标准

判定标准是评审者用来对照的参考基准——Agent 无法辩驳的依据。开始排查前，先为每个切片设定标准，并让它成为演示，而不是描述：

• 代码库 — 一条从源到汇的路径，附带具体的触发输入，或一份能够触发该路径的书面 PoC。“攻击者控制 id，查询没有租户范围限制，这是一个会返回其他租户记录的请求。”
• 二进制文件 — 一份可复现的输入，以及故障分析：崩溃、状态损坏，以及控制是否受到影响。消毒器报告（ASan/UBSan）或模糊测试器最小化后的用例符合标准；含糊其辞则不符合。
• 在线目标 — 观察到的异常行为，已复现，并捕获请求/响应。只有在复现并控制环境变量后，盲注和基于时间的信号才算数。

如果某个切片无法明确具体的判定标准，就说明拆分得还不够细。继续拆分，直到每个部分都有可供评审者核查的明确通过/失败条件。

实际运行

在 Agent 式测试框架（Claude Code，配合子 Agent）中，循环可直接对应到以下角色：

• 负责人是你的主上下文：负责维护切片列表和测试进度，并进行调度。
• 每个构建者和评审者都是拥有独立全新上下文的子 Agent——评审者若与构建者共享上下文，就会继承其盲点和乐观倾向；相互隔离正是关键所在。
• 将切片列表、候选项工作清单，以及每个候选项的结论，持久化到测试记录（maintaining-engagement-state）中——循环可能持续很久，必须能在重启后继续运行，而无需重新排查已排除的路径。
• 根据分配给你的预算调整并行任务数量，并记录未能覆盖的内容。一场悄悄抽查了四十个切片中的十个，却报告一切正常的测试活动，甚至不如一场检查了十个并如实说明的活动。

自动化发现工具只是切片中的构建者，不能替代整个循环。模糊测试器（AFL++、libFuzzer）、污点分析引擎（CodeQL）或扫描器会生成候选项；这些候选项仍须交由独立评审者审核，并遵循相同的判定标准。未经验证就直接将工具输出认定为发现，正是这套测试框架要防止的问题。

范围与授权

发现活动比单次测试危险得多，因为它会并行展开并反复迭代。

• 授权必须覆盖整个目标和测试强度。“你可以测试 X”并不意味着“你可以持续模糊测试 X 的生产环境解析器，直到它崩溃”。发现技术——模糊测试、注入扫描、反序列化探测——可能导致服务中断并损坏数据。并行展开前，先以书面形式确认目标、环境（优先选择非生产环境）和允许的测试强度。
• **指定一个目标，就会牵涉第三方资产。**它的登录通过身份提供商进行联合认证，资产位于 CDN 后方，它的“子域名”实际上是一个你无权触碰的 SaaS 租户。开始排查前，先确认资产归属，并确保每个构建者都在授权范围内——并行展开很容易在不知不觉中越界。
• **在你不拥有的软件中发现新漏洞，就负有披露义务。**此前未知的漏洞应按照协调披露流程处理，而不是当作战利品。通过 reporting-security-findings 提交。
• **不要超出判定标准，将漏洞武器化。**判定标准要求触发效果得到演示。目标是证明汇点受到控制；针对在线第三方系统制作一个完整可用的漏洞利用程序，则需要单独授权，而你很可能并未获得该授权。

应拒绝的自我辩解

• “猎手说它可以被利用，所以这就是一项发现。” 猎手恰恰是不能做出这个判断的 Agent。必须有独立评审者或真实证据，否则它就只是一个假设。
• “它看起来可以触达／那个缓冲区看起来没有上限／这个错误暗示存在注入。” 这些都只是候选项，不是漏洞。标准是证明触发条件，而不是看起来有道理。
• “评审者和构建者可以共享上下文来节省 token。” 这样评审者就会继承构建者的盲点，并为其乐观判断打分。彼此隔离就是方法；打破隔离，就失去了它的价值。
• “我们已经反复尝试够久了；把它升级为发现，免得白费功夫。” 未经证实的发现并不算小胜，而是假阳性，会损害真正发现的可信度。把它降级为有记录的线索；不要把它包装成发现。
• “一个 Agent 什么都没找到，所以这个切片没有问题。” 一名猎手没有发现问题，只能说明一种搜索策略没有发现问题。只有经过充分搜索并由评审者确认，才能说没有问题；不能因为“第一轮什么也没发现”就下结论。
• “已排除的候选项不值得记录。” 有检查、有结论和理由的路径就是覆盖范围。把它删掉，下一轮就会重新搜索，或者更糟，报告为未经测试。
• “拆分任务只是额外负担；直接让一个 Agent 检查整个仓库就行。” 这样它就会给自己打分，并停在第一段看似合理的分析上。拆分任务才能实现独立判断和并行处理。

参考资料

• auditing-code-for-vulnerabilities — 用于审查源代码的逐切片猎手
• analyzing-binaries — 用于审查编译目标的逐切片猎手
• testing-web-applications、testing-apis — 用于黑盒测试的逐切片猎手
• reporting-security-findings — 用于提交已证实的发现
• maintaining-engagement-state — 用于记录切片列表、工作清单和结论
• CWE 和 OWASP ASVS，用于对猎手要查找的问题进行分类