Proof-Based Findings: Only Verified Vulnerabilities in Your Report

Why do most scanners produce noisy, hard-to-use reports?

Traditional vulnerability scanners match observed signals against a database of known vulnerability patterns. A server returning a specific banner gets flagged. A version number matches a known CVE — flagged. A header is missing — flagged. None of these detections confirm whether the vulnerability is actually exploitable in your specific environment.

The result is thousands of findings, most of which are either false positives, unexploitable due to compensating controls, or too vague to act on without security expertise. A scan report with 3,000 items forces you to hire a security analyst just to triage the output.

How does VeilScan's proof standard work?

VeilScan applies a tiered proof standard to every finding before it enters your report:

• Critical findings require a reproducible proof of impact. Examples: a captured HTTP response demonstrating data exposure (e.g. environment variables returned in a response body), a confirmed SQL injection trigger with database output, a verified subdomain takeover with DNS control demonstrated, or a confirmed XSS payload execution. The finding must be reproducible from outside the network, with no internal access or credentials.
• High findings require confirmed evidence. Examples: a verified service fingerprint on an open port, a confirmed weak cipher suite accepted by the TLS handshake, a validated exploit signal on an exposed admin panel. Theoretical or pattern-matched detections alone are not sufficient.
• Unverified signals are automatically downgraded to Medium or Low severity, or filtered out entirely. They do not inflate your Critical and High counts.

What does a proof artifact look like in a report?

In your VeilScan dashboard and PDF report, each Critical or High finding includes the proof evidence alongside the finding description. This may be:

• A truncated captured HTTP response showing the data that was exposed
• A curl command and its output demonstrating the vulnerability is reproducible
• A DNS lookup confirming a dangling CNAME points to an unclaimed service
• A TLS handshake record confirming a weak cipher was negotiated

Proof artifacts serve two purposes: they confirm the finding is real, and they give your engineering team the exact evidence they need to understand and reproduce the issue for remediation verification.

How does proof-based scanning affect false positive rates?

Proof-based scanning dramatically reduces false positives at Critical and High severity. Because these findings require reproducible exploit evidence, findings that would be false positives in a traditional scanner — version-matched CVEs on patched systems, theoretical misconfigurations blocked by WAF, weak cipher suites not actually negotiated — are filtered out at the verification step.

The remaining Medium and Low findings (where a full proof standard is not applied) may include some theoretical signals. These are presented at lower severity with appropriate context.

See: What is a False Positive? · What is Verified Exploitability?

What are the most common questions?

Does proof-based verification slow down scans?

Slightly. Verification steps require additional requests and processing per finding candidate. VeilScan scans typically complete within 90 to 120 minutes, which includes full verification. For most domains this is fast enough to run on a continuous schedule without operational impact.

Is proof-based scanning available on the free plan?

The free plan detects Critical and High findings but does not show their full proof evidence — the count is visible but the findings are locked. Full proof evidence for all findings is available on paid plans. See all plans.

What if a finding is real but VeilScan cannot prove it?

If a genuine vulnerability cannot be confirmed with external evidence — for example, it requires internal network access or authenticated credentials — VeilScan will not report it at Critical or High severity. VeilScan is an external-only scanner. For internal vulnerabilities, a manual penetration test or internal scanner is required.