Confidence pipeline¶

Vex Raptor's core design principle is evidence over volume. A detection is only useful if you can trust it, so every finding carries a confidence level that tells you how it was verified — not just that a scanner flagged it.

The golden rule¶

Double-signal rule

A finding is promoted to CONFIRMED only when a second, independent signal reproduces it. A single reflection, a single error message, or a single timing blip is not enough.

The second signal is one of:

A re-probe — a different, independent payload that must trigger the same effect (the check is fail-closed: any timeout or error → not confirmed).
An out-of-band (OOB) callback — for blind classes, an external interaction proves execution. Requires an OOB collaborator: the default local backend only fires against local/private targets; real external targets need a self-hosted interactsh (see OOB below).
A second tool — the same class confirmed by another source raises confidence.

Confidence levels¶

Findings are graded and the grade is shown in the report:

Level	Meaning
EXPLOITED / CONFIRMED	Reproduced with a real payload; ships with a proof of concept
OBSERVED / HIGH	Strong single-signal evidence; confirmation was inconclusive
INFO	Reconnaissance context (open port, header, hardening note)
UNVERIFIED	Low-confidence signal that needs a manual look

Low-confidence findings are labelled as such rather than presented as facts.

How false positives are suppressed¶

Several layers reduce noise before a finding reaches you:

Baseline & SPA guard — a marker already present in the clean response, or a single-page app that reflects everything, is detected and does not trigger a finding.
Content-type awareness — a JSON API is not flagged for browser-only issues like reflected XSS.
Anti-false-positive regression corpus — a test suite of realistic high-FP-probability targets asserts that safe targets produce zero CONFIRMED findings; it runs in CI on every change.
Feedback learning — finding types repeatedly marked as false positives are automatically down-ranked over time, without ever touching CONFIRMED findings.

An honest framing

Vex Raptor is engineered for very low false positives, not zero. No autonomous tool is infallible. What the pipeline guarantees is that anything labelled CONFIRMED is reproducible and comes with evidence — and that everything less certain is labelled accordingly, so you always know what was proven.

Out-of-band (OOB) confirmation¶

Blind vulnerability classes (blind SSRF, blind SQLi, some RCE) cannot be confirmed from the HTTP response body alone. Vex Raptor confirms them through an OOB collaborator. Two backends:

local (default) — in-process collaborator. Confirms blind classes only against local/private targets (e.g. a Docker lab); against real external targets it is a silent no-op (the target cannot reach an in-process listener).
interactsh (real external targets) — points at a self-hosted interactsh server (OOB_MODE=interactsh, INTERACTSH_URL=…). Required for OOB-confirmed blind classes on internet-facing targets. Vex Raptor does not host this for you.

OOB_ENABLED=true             # default on
OOB_MODE=interactsh
INTERACTSH_URL=http://interactsh:1337
INTERACTSH_DOMAIN=oast.example.internal   # must match server -domain

Status

A managed OOB collaborator is on the roadmap. Today, OOB confirmation on real external targets requires running interactsh yourself. Without it, blind classes are still reported at heuristic confidence (e.g. time-based) and are not labelled as OOB-confirmed.

Findings from the binary arsenal¶

When the FULL/AI stream runs the bounded arsenal_lite phase (nmap service detection + nuclei high/critical templates), those findings inherit the tool's confidence rather than passing through the double-signal re-probe. They are labelled by source so you can tell engine-verified findings from template-matched ones. See Scan depths.