Security Vuln Gauntlet

The Gauntlet Loop applied to finding real vulnerabilities: a HUNTER (builder) proposes candidates and a blind VALIDATOR (critic) demands a working PoC before anything counts. The bar is exploitability + CWE mapping + real precedent. Covers web, API, binary/memory, and cloud/IaC.

Kept separate from the core gauntlet-loop skill because its triggers and safety requirements differ: written authorization (ROE) is mandatory and every PoC must be non-destructive. The method itself is the core loop.

SCOPE AND AUTHORIZATION — mandatory

Use only on assets you own or are authorized in writing to test. If there is no ROE, STOP and ask the user for one. Read references/safety-and-scope.md first.

Every PoC must be non-destructive: no data destruction, no lateral movement, no exfiltration, no denial of service. This is a defensive/AppSec tool. Unauthorized access is a crime in most jurisdictions (CFAA in the US, the Computer Misuse Act in the UK, equivalent computer-crime statutes elsewhere) and the operator carries that responsibility.

When to use it

Reviewing or pentesting an authorized codebase, service, binary, or cloud configuration — or triaging an existing scan down to what is actually exploitable.

Role mapping

The bar (three axes, all required)

1. Exploitability: a working PoC or equivalent evidence under the target's actual conditions — not "theoretically possible".
2. CWE mapping (prefer the CWE Top 25): map to a meaningful weakness class, e.g. CWE-89, CWE-79, CWE-787, CWE-416, CWE-918, CWE-862, CWE-22, CWE-502.
3. Real precedent (never fabricated): point to the real-world vulnerability class or a genuine CVE to calibrate severity and credibility. If you cannot find a precedent, write "novel/uncertain" — do not invent a CVE ID.

The loop

1. Scope, bar, and budget. Read the ROE first.
2. LEAD split: map trust boundaries, entry points (attacker-controlled input), dangerous sinks, and high-value assets (auth, money, PII, RCE surface). Divide into hunting units.
3. HUNTER × N (parallel, clean contexts): each returns {location, source, sink, taint path, preconditions, confidence, PoC idea}.
4. VALIDATOR (blind): for every candidate, run Reachability → Taint → PoC in order. PASS only with evidence. Techniques: references/false-positive-killing.md.
5. Score against the bar: CWE, CVSS, precedent. Drop anything below the bar.
6. Repeat: feed FAILs back to the hunters; chase chains and variants; run longer; record coverage gaps.
7. Report: confirmed findings (with PoC) kept strictly separate from unconfirmed ones, each with remediation.

Source → sink checklists

Web, API, binary/memory, and cloud/IaC are covered in references/checklists-by-domain.md, with OWASP Top 10 / API Top 10 / ASVS / CWE / CIS mappings, sanitizer-bypass notes, and the per-domain bar signals.

Worked examples

• Web (path traversal, with a PoC plus a killed false positive): references/example-web-run.md.
• IDOR/API, binary crash triage, and cloud IAM privilege escalation: inside references/checklists-by-domain.md.
• An end-to-end run across several hunting units: ../../examples/example-security-run.md.

Output

For every CONFIRMED finding: title, CWE ID, severity (with a suggested CVSS vector), the non-destructive PoC or evidence, the source → sink path, preconditions, and remediation. Findings without a PoC are reported as UNCONFIRMED in a separate section. Include the coverage map and a reference to the ROE.

References

• references/safety-and-scope.md — ROE template, PoC constraints, logging.
• references/false-positive-killing.md — the reachability → taint → PoC gates.
• references/checklists-by-domain.md — web / API / binary / cloud (source → sink + bar + OWASP/CWE/CIS).
• references/example-web-run.md — one loop round with a PoC.