A scanner’s "critical" is not a break-in

Most security tools grade risk. They crawl your app, match responses against a signature list, and hand back a PDF of severities: twelve criticals, forty highs, hundreds of mediums. It looks like progress. It usually is not.

A severity is a guess about what an issue could mean. It is not a demonstration that the issue is real, reachable, and exploitable in your environment. The gap between “this looks like SQL injection” and “here is the exact request that read your customers’ data” is the whole job, and a scanner does not cross it.

Why the guess is expensive

Every unverified “critical” costs an engineer time. Someone has to reproduce it, decide whether it is real, and either fix it or mark it a false positive. Teams routinely spend more time triaging a scanner’s output than they would have spent fixing the handful of issues that actually matter.

Worse, the grading is often wrong in both directions: reflected input flagged as a vulnerability that the framework already escapes, and a genuinely dangerous flaw rated “informational” because it did not match a pattern. You cannot plan remediation around a number a machine assigned without ever opening the door.

Proof changes the conversation

SpikeFlare does not file a severity. It files a break-in. For each finding it chains the weakness into a working exploit, then a deterministic oracle measures whether real server-side state actually changed. Only then, and only after the proof re-runs from a clean session, does it become a finding.

The result reads differently. Instead of “possible broken access control, high,” you get the request that read another tenant’s invoice, the data it returned, and the one-line fix. There is nothing to triage, because the proof is the triage.

This is why our reports run shorter than a scanner’s. We would rather miss a maybe than ship one. For an output a human has to act on, a proof-carrying finding is simply the more useful one.