What a real proof-of-concept looks like

We have one rule that shapes everything else: if a finding’s proof does not re-execute from a clean, isolated process, we do not file it. No reproducible proof, no finding.

That sounds strict. It is. It is also the only honest way to tell you that something is real.

The anatomy of a proof

A SpikeFlare proof is not a screenshot or a severity label. It is a replayable artifact with four parts:

• The exact request that crossed the line, with the response that proves it worked.
• The measured state change on the server: the row that was read, the balance that moved, the record that was created.
• A clean re-run, from a fresh session with no leftover state, that reproduces the result.
• The business impact in plain English, and a fix aimed at the root cause rather than the symptom.

The clean re-run is the part most tools skip, and it is the part that matters most. Plenty of “findings” work once, in a dirty session, because of state left behind by earlier testing. Re-running from zero is what separates a real vulnerability from an artefact of the test itself.

Why we hold the line

Holding proof to this standard has a cost: we file fewer findings than a scanner reports. We are comfortable with that. Precision over recall is a deliberate choice, because the alternative, a long list of maybes, is exactly the thing that makes security reports useless.

On the OWASP Benchmark this discipline shows up as a confirmed-tier false-positive rate of 0.00 across the non-vulnerable cases. In your environment it shows up as a report you can act on without re-checking our work.

Breaks in. Proves it. The second half is the hard part, and it is the part we refuse to fake.