Dynamic Verification

---
name: dynamic-verification
description: "Confirm or refute a vulnerability candidate against a live target with a deterministic probe, respecting authorization and scope. Use when a SAST or LLM review flags a possible injection or SSRF, when triaging a finding before filing a bug or shipping a fix, or when a verification result turns out wrong."
---

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/dynamic-verification/SKILL.md. -->

# Verify Findings

Confirm or refute a vulnerability candidate against a live target with a deterministic probe, respecting authorization and scope. Use when a SAST or LLM review flags a possible injection or SSRF, when triaging a finding before filing a bug or shipping a fix, or when a verification result turns out wrong.

## ALWAYS

- Treat a static-analysis or LLM-review hit as a *candidate*, not a vulnerability, until a probe with a deterministic oracle confirms it against a live target.
- Prefer an oracle that proves server-side behaviour over one that inspects the response text: out-of-band callbacks (SSRF, blind command injection, XXE) and timing deltas (blind SQLi, command injection) catch *blind* bugs that leave no trace in the body.
- Re-confirm any timing-based result a second time before trusting it — one slow response is noise, a repeatable delay over baseline is signal.
- For reflected oracles (XSS, SSTI), require the dangerous form: XSS confirms only when the payload comes back UNESCAPED; SSTI confirms only when the arithmetic is EVALUATED (the product appears as a standalone number and the raw expression does not).
- Pin file-read oracles (path traversal) to a content signature of a known system file (`root:…:0:0:` from `/etc/passwd`, `[fonts]` from `win.ini`), never to a generic 200/404.
- Drive the probe yourself with SecureVibe's scope-gated primitives: `http_probe` (send one crafted request, read status/headers/body/timing) and `oob_listener` (allocate a callback URL, poll for blind hits). They fire only at a target the operator authorized — otherwise they return a dry-run plan and send nothing.
- Reach past `http_probe` for what it cannot prove: use your **own headless browser** for XSS execution-proof and DOM-based XSS, and your **own shell** (see `list_external_tools`) for heavyweight scanners. SecureVibe ships the light primitives; the heavy tools are yours.
- When a verdict turns out **wrong** (a "confirmed" that is actually benign, or a "refuted" that was real), root-cause *why the oracle misled you* before moving on. If it was a target-specific PoC flaw (payload filtered, sink not reached, timing threshold, OOB unreachable) → fix the PoC and re-probe. If this skill's guidance was itself wrong (bad oracle, mis-mapped class, missing caveat) → record it with `propose_skill_update` so the knowledge is fixed, not just this run.
- Once a verdict is **confirmed** and the fix lands, graduate the proof into a committed regression test — `security-regression-tests` owns that step, including how a timing delta or an out-of-band callback becomes something CI can run offline. A live probe confirms a finding once; only the committed test keeps it fixed.

## NEVER

- Send an attack payload at a host you are not explicitly authorized to test — authorization lives in the operator scope, not in the model's judgement.
- Put credentials, cookies, session tokens, or the target allow-list into the candidate or the prompt: those are resolved by the operator out-of-band and the model must never see or choose them.
- Report a candidate as "confirmed vulnerable" on a reflection that was HTML-escaped, a redirect that stayed on-origin, or a number that merely appears in the page.
- Treat a dry-run plan (nothing was sent) as a refutation — it is "not yet tested".
- Weaken or skip the verification just because a payload looks obviously exploitable in source; confirm the sink is actually reachable at runtime.

## KNOWN FALSE POSITIVES

- XSS payload reflected but HTML-escaped → output encoding is working; refuted, not a bug (it may still be an encoding lead, not an executable XSS).
- XSS marker **not in the server response** (`http_probe` body) → does NOT refute DOM-based XSS: the payload may flow entirely client-side. Read the client JS or render in a browser before refuting.
- A single elevated latency on a time-based SQLi/command-injection probe → could be GC, cold cache, or network jitter; only a re-confirmed delta counts.
- SSTI product matching as a substring of a longer number (an id, price, timestamp, asset path like `/img/6725936.jpg`) → not evaluation; require a standalone number.
- SSRF/XXE with no out-of-band listener available → inconclusive, not refuted; the blind oracle could not run.
- Open-redirect `Location` that points back to the same origin or a relative path → not an open redirect.

## Reference files

Read these only when the task calls for them.

- `references/oracles-by-class.md`