Proof-based scanning
Proof-based scanning: vulnerabilities that are verified, not guessed
Most scanners flood you with "possible" findings. SecuProbe replays each one and runs a control request before it counts — so your report shows vulnerabilities that were actually reproduced, with far fewer false positives.
Why automatic scanners drown you in noise
The usual complaint about automated security scanning is not that it misses things — it's that it cries wolf. A single scan can return a hundred "high" findings, half of which disappear the moment someone checks them by hand. Teams learn to distrust the tool, the report gets ignored, and the real vulnerability hides in the noise.
The root cause is that many scanners report a signal — a header, an error string, a status code — without proving it comes from an actual weakness. A page that answers 200 to everything, a firewall that returns 403, a generic error message: each can look like a finding without being one.
What proof-based scanning means at SecuProbe
SecuProbe treats a finding as a claim that has to be proven before it is counted. For every active test, the scanner keeps the exact request that triggered the result, then does two things. First it replays that request: the vulnerable behaviour has to appear again, so a one-off network glitch never becomes a finding. Then it sends a control request — the same request with the payload removed, a parameter set to a neutral value, or a neighbouring path that should not exist. If the control request produces the same signal, the result did not come from the payload, and the finding is rejected.
Only a finding that reappears on replay and goes quiet on the control request is confirmed. When a module obtains an out-of-band confirmation — a callback it alone could have triggered — the finding is confirmed outright.
Three levels of confidence, and what counts
Every finding carries one of three states. Confirmed means replay succeeded and the control request came back clean. Likely covers configuration and informational findings observed directly, or an active finding whose proof could not be replayed on this target. Unconfirmed means the signal could not be reproduced, or appeared even without the payload.
This matters for your score: unconfirmed findings are listed separately and do not count toward your SecuScore. The number you report to a client or a board is built from evidence, not from guesses.
The evidence attached to every finding
A confirmed finding is only useful if you can see why. SecuProbe stores, for each one, the request it sent and an excerpt of the response for active tests, the observed value for configuration findings, numbered reproduction steps, a ready-to-copy curl command, a CVSS 3.1 score and a CWE reference. Cookies, tokens and credentials are stripped before the proof is stored, and the evidence is encrypted at rest.
You can re-run the proof request for a single finding in under 30 seconds, without spending a scan from your quota — useful to confirm a fix.
Honest by design: what proof-based scanning does not promise
Proof-based scanning reduces false positives sharply; it does not claim to eliminate every one. Network validation is time-boxed so a fast scan stays fast, and on some targets a proof genuinely cannot be replayed — those findings fall back to the module's own confidence rather than being inflated.
If you still spot a finding you disagree with, one click marks it a false positive: it stays visible but stops counting toward your score, and the signal helps us tune detection.
Proof that travels: reports, CI/CD and tickets
Because each finding carries its own evidence, that proof follows it everywhere. The PDF report and the read-only share link show it to a client as evidence of your checks. In CI/CD, findings you have accepted or marked as false positives — and findings that could not be confirmed — never fail the build.
When you open a Jira or Linear ticket from a finding, it carries the redacted proof and the remediation, so the developer who fixes it never has to reproduce it from scratch.