What Is Proof-Based Vulnerability Scanning?

Why do traditional vulnerability scanners produce noisy reports?

Traditional vulnerability scanners work by matching observed signals against databases of known vulnerabilities. They detect a software version string and cross-reference it against CVE databases. They check for the presence of a header or the absence of a control. They see a configuration pattern that matches a known risk.

None of these detections confirm whether the vulnerability is exploitable in the specific target environment. A server might run a vulnerable version of software but have compensating controls — a WAF, patched behavior, or non-default configuration — that make the vulnerability unexploitable. The scanner flags it anyway.

The result is a finding list that mixes confirmed, exploitable vulnerabilities with theoretical detections and false positives. Separating the two requires a security analyst — someone with expertise to judge which findings are real and which are noise.

What does proof-based scanning require?

Proof-based scanning adds a verification step between detection and reporting. For a finding to appear at Critical or High severity, the scanner must produce reproducible evidence of exploitability:

• Data exposure findings — a captured HTTP response containing the sensitive data. A finding that "might expose environment variables" requires an actual response body showing environment variables before it is reported as Critical.
• SQL injection — a payload confirmed to produce database output. Version detection of a potentially vulnerable framework is not sufficient; the injection must be executed and the output captured.
• Subdomain takeover — DNS control demonstrated by claiming an unclaimed service and receiving a response from the controlled subdomain. DNS pointing to a decommissioned service is not sufficient without confirming the service is claimable.
• TLS weakness — the weak cipher suite confirmed as negotiated in an actual TLS handshake, not just advertised as supported.
• Sensitive file exposure — the file contents confirmed as accessible, not just the path as potentially existing.

What happens to findings that cannot be proven?

In a proof-based model, findings that cannot be verified with concrete evidence are not silently dropped — they are downgraded. A detection without proof evidence becomes a Medium or Low finding, signalling that the signal exists but exploitability is not confirmed. This means the Critical and High section of your report contains only verified findings, while lower-severity sections may include theoretical signals for awareness.

Why does proof-based scanning matter for non-security teams?

The value of proof-based scanning is that it eliminates the need for expert triage. When every Critical and High finding in a report is verified, the report is directly actionable without a security analyst to filter the noise. A CTO or senior engineer can read the Critical findings and start fixing them without spending time evaluating whether each one is real.

This is the core design principle behind VeilScan: deliver a shorter list of verified, high-confidence findings that a non-security engineer can act on, rather than a comprehensive list of potential issues that requires security expertise to interpret.

See: Proof-Based Findings feature · What is Verified Exploitability? · What is a False Positive?

What are the most common questions?

Does proof-based scanning miss real vulnerabilities?

Yes. A proof-based scanner will not report a vulnerability at Critical or High severity if it cannot confirm exploitability from the outside. A real vulnerability protected by a compensating control may not be provable externally. This is an intentional tradeoff: proof-based scanning prioritises signal quality over coverage. For complete coverage including compensating controls, a credentialed internal scan or manual penetration test is required.

Is proof-based scanning slower than traditional scanning?

Slightly. Verification steps require additional requests and processing. VeilScan scans typically complete within 90 to 120 minutes including full verification — fast enough for continuous monitoring on a weekly or monthly schedule.

Which vulnerability types benefit most from proof-based verification?

The biggest impact is on findings that are commonly false positives in traditional scanners: SQL injection (often flagged based on error patterns without confirmed exploitation), subdomain takeover (often flagged based on CNAME patterns without confirming claimability), TLS weakness (often flagged based on cipher advertising without confirming negotiation), and sensitive file exposure (often flagged based on path guessing without confirming file accessibility).