Dynamic verification

<!-- Native skill bundle for agent-skills (cross-tool convention). 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 (the agent runs the probe, respecting authorization and scope)

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.

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.