How Vex Raptor decides what's CONFIRMED

Security buyers have learned to distrust severity scores. A scanner fires CRITICAL because a payload echoed once — then your team spends a day proving it was a WAF reflection, a cached error page, or a SPA catch-all. The label said "confirmed." The evidence said maybe.

Vex Raptor's confidence model exists to break that pattern. CONFIRMED is not a default — it is earned per vulnerability hypothesis, only after independent signals agree under rules we can explain and test.

One hypothesis, accumulating signals

When the engine probes a target, it does not flip a boolean on the first interesting response. Each candidate issue gets a signal accumulator: a bucket that collects every piece of evidence tied to that specific hypothesis (same flaw, same location, same attack class). Probes append signals with a class, a strength, and — when applicable — whether a negative control passed.

Only after signals are in does the accumulator evaluate confidence. One reflection, one timing blip, or one heuristic match is never enough to reach CONFIRMED on its own.

Signal classes (simplified)

Signals are tagged by how strongly they support exploitation — not by how loud the alert looks:

DIRECT       → sole proof (browser dialog fired, OOB callback received, independent math payload evaluated)
DIFFERENTIAL → meaningful delta vs a baseline or negative control (timing, response shape)
CORRELATIVE  → supporting evidence that aligns with the hypothesis but is not standalone proof
HEURISTIC    → pattern match or scanner-style indicator — never enough alone for CONFIRMED

The CONFIRMED bar

CONFIRMED requires evidence that would convince a skeptical engineer, not just an automation rule:

if any signal is DIRECT:
    confidence = CONFIRMED
elif any DIFFERENTIAL signal passed negative_control:
    confidence = CONFIRMED
else:
    derive HIGH / MEDIUM / LOW / UNCONFIRMED from remaining signal mix

A DIRECT signal is proof that the vulnerability behaved as exploited — a dialog event, an out-of-band hit, a payload that evaluates independently of a single reflection. A DIFFERENTIAL signal alone is not enough: it must have passed a negative control — a deliberate test designed not to fire if the flaw is not real (baseline timing, benign payload, authenticated vs unauthenticated comparison). That is how we filter coincidence from causation.

The five confidence tiers

Every finding exports one of five labels — the same five documented on our Evidence page, but here is the machinery behind them:

CONFIRMED   → ≥1 DIRECT, or DIFFERENTIAL with negative control passed
HIGH        → ≥2 independent CORRELATIVE signals, or DIFFERENTIAL without control
MEDIUM      → 1 CORRELATIVE, or mixed non-heuristic support
LOW         → heuristic-only signals (stacked heuristics never exceed LOW)
UNCONFIRMED → no qualifying signals

Severity follows confidence

Confidence and severity are coupled. A raw CRITICAL severity from the probe is not what lands in your report unchanged — the confidence tier downgrades it unless the evidence truly supports it:

CONFIRMED   → CRITICAL stays CRITICAL
HIGH        → CRITICAL downgrades to HIGH
MEDIUM      → CRITICAL → HIGH, HIGH → MEDIUM, …
LOW         → each tier drops one step further
UNCONFIRMED → everything becomes INFO

Only CONFIRMED preserves a CRITICAL label as CRITICAL. Everything else steps down at least one notch; UNCONFIRMED collapses to INFO regardless of what the initial probe suggested. That is intentional: we would rather under-state than ship a board-slide CRITICAL built on a single automated guess.

What this means in practice

When you see CONFIRMED in a Vex Raptor report, you are not looking at "the scanner was confident." You are looking at a hypothesis that survived multi-signal review — direct proof, or differential evidence with a control that did not fire. HIGH, MEDIUM, LOW, and UNCONFIRMED are honest buckets for everything that still needs human judgment. The public Evidence page describes what we promise; this is how the engine keeps that promise.