How We Use /goal to Find Bugs in Patch the Planet

src/AI/AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md

@@ -164,6 +164,53 @@ This is token-heavy and noisy, but it is very effective at surfacing **simple hi
 
 ---
 
+## 7. Goal-Driven Agentic Variant Analysis
+
+When using autonomous audit agents, define **what counts as a valid finding** and avoid over-specifying **how** the model must search. A weak prompt such as `find bugs in X` has no measurable stopping condition; a stronger goal defines one reportable outcome, the attacker model, forbidden assumptions, required evidence, and where the final report must be written.
+
+### Goal design checklist
+
+- Start from a repo-local **`THREAT_MODEL.md`** or an equivalent [Threat Modeling](../generic-methodologies-and-resources/threat-modeling.md) artifact.
+- Let the model draft the goal, then ask it to **red-team its own wording** and enumerate lazy shortcuts, invalid assumptions, or superficial completion paths.
+- Define **attacker-controlled inputs**, **trust boundaries**, **required impact**, **duplicate-check scope**, **persistence requirements**, **safe proof requirements**, and the **stopping condition**.
+- Explicitly reject findings that require out-of-scope prerequisites such as attacker-controlled local config, CLI flags, environment variables, installed plugins, source edits, credentials, privileged admin access, or prior code execution.
+- Measure real repository coverage with tooling such as `aicov` instead of trusting an agent that claims it reviewed the full codebase.
+
+For remote-code-execution hunting, keep the outcome broad enough to preserve exploration freedom but narrow enough to stay measurable: prioritize deserialization, YAML/JSON/protobuf parsers, dynamic imports, `eval`, template engines, archive extraction, redirects, generated hooks, websocket streams, subprocesses, and filesystem side effects, while still requiring a minimal safe proof before promotion.
+
+### One measurable outcome per agent
+
+Do not combine **bug discovery**, **maximum coverage**, and **multiple attack surfaces** in the same optimization target. A practical orchestration is:
+
+1. Run a reconnaissance pass to inspect the repository and rank the most promising attack surfaces.
+2. Spawn **one autonomous session per surface**, each tasked with finding **exactly one** valid bug.
+3. Keep a separate open-ended session for code that was not assigned to a specialized agent.
+4. Feed promising paths into deeper [Fuzzing Methodology](../generic-methodologies-and-resources/fuzzing.md) or [Source code Review / SAST Tools](../network-services-pentesting/pentesting-web/code-review-tools.md) workflows only after the surface is prioritized.
+
+This avoids a common failure mode where the agent over-optimizes either coverage or exploitability and neglects the other.
+
+### Variant analysis and differential static rules
+
+When mining historical vulnerabilities, provide a **one-sentence description of the bug class** instead of the exact root cause, stack trace, or patch hunk. Exact details anchor the model to one implementation and often suppress semantically related variants.
+
+A useful hybrid workflow is to convert a historical bug/CVE into a **Semgrep** rule and validate it differentially before trusting it:
+
+1. The rule **must match** the known vulnerable revision.
+2. The rule **must stay silent** on the patched revision.
+3. Only then should it be executed against related codebases or nearby subsystems.
+4. Every hit remains a **candidate** until attacker reachability, exploitability, and security impact are reviewed.
+
+### Multi-stage validation for AI findings
+
+Autonomous findings should pass several independent gates before disclosure:
+
+1. **Security gate**: classify work items as `skip`, `no_variant`, or `bug_found`.
+2. **Judge 1**: verify that the candidate crosses a real security boundary and is not just a correctness bug.
+3. **Judge 2**: use an independent model for a PoC-focused review against the target threat model.
+4. **Human review**: reproduce safely, deduplicate against existing issues/PRs, and confirm the impact before reporting upstream.
+
+Treat `no bugs found` as an **intermediate result**, not as successful completion, unless the goal explicitly defines exhaustive failure conditions.
+
 ## Putting It All Together
 An end-to-end CRS (Cyber Reasoning System) may wire the components like this:
 
@@ -187,5 +234,6 @@ graph TD
 * [Strix](https://github.com/usestrix/strix)
 * [GitHub Copilot community security-review skill](https://github.com/github/awesome-copilot/blob/main/skills/security-review/SKILL.md)
 * [Trail of Bits – AIxCC finals: Tale of the tape](https://blog.trailofbits.com/2025/08/07/aixcc-finals-tale-of-the-tape/)
+* [Trail of Bits – How we use /goal to find bugs in Patch the Planet](https://blog.trailofbits.com/2026/07/28/how-we-use-goal-to-find-bugs-in-patch-the-planet/)
 * [CTF Radiooo AIxCC finalist interviews](https://www.youtube.com/@ctfradiooo)
 {{#include ../banners/hacktricks-training.md}}