The short version
On 34 scored targets, the scanner reported 0 false positives. Every finding was checked against ground truth taken from the application's source code or documentation. The targets are our own test targets, not customer sites. Last measured on 2026-10-23.
| Setup | Targets | True positives | False positives | Known misses |
|---|---|---|---|---|
| Isolated Docker benchmark | 20 | 218 | 0 | see limits below |
| Public test range, scanned by production | 14 | 58 | 0 | 3 |
The targets
Isolated Docker benchmark (20 targets).
- Deliberately vulnerable training apps, pinned to exact image versions: OWASP Juice Shop, DVWA, WebGoat, OWASP Benchmark, bWAPP, Mutillidae, NodeGoat and VAmPI.
- Our own fixtures: vulnerable and safe twins of the same pages, a WAF in front of an app, a login-protected app, a store with a separate API host, and a static site.
- Four hardened controls with nothing deliberately wrong: WordPress, Django, Next.js and Laravel, each configured by the vendor's own security documentation. These matter most, because ordinary maintained sites are where false positives show up.
Public test range (14 targets). Real hosts on the internet, scanned by the production scanner exactly as a customer scan runs: ten test apps on different stacks (Node, Flask, Ruby, .NET, Tomcat, WordPress, a SPA, a static site, a site behind a WAF, Juice Shop) and the same four hardened controls, three behind Cloudflare and one served directly.
Five applications (Juice Shop and the four hardened controls) are scored in both setups, once in Docker and once on the public internet, and each setup counts as its own target.
How a finding is checked
- Ground truth first. For every target we list what is really vulnerable, and each entry names its source: a file and line in the app's source code, the vendor's documentation, or an independent request we made and recorded. A scanner result is never used as ground truth.
- Every reported finding is matched. A finding that matches a ground-truth entry is a true positive. A finding that matches nothing is triaged by hand: if it is real, it is added to the ground truth with its source; if it is not, it is counted as a false positive and fixed in the scanner. In the benchmark, the number of findings still waiting for that triage is 0.
- Every fix has a test. A scanner change ships only with a regression test that failed before the change and passes after it.
- Every deploy is gated. Before a release reaches production, CI scans our fixtures and the four hardened controls. A new false positive fails the deploy.
What the numbers do not cover
- Measured on our targets, not yours. Your site may have a stack or a configuration we have not tested. If a finding looks wrong, mark it as a false positive and tell us - that is how the benchmark grows.
- Large applications. A scan crawls up to 100 pages. On the OWASP Benchmark, which has 2,740 test pages, the scanner found 12 of the 735 scored issues. Large apps get partial coverage.
- Known misses. The live range has 3 known false negatives, kept on record.
- Not tested, by design. Anything that can only be confirmed by changing data: stored XSS, file upload, account takeover, business-logic flaws. These need a manual penetration test.
- Not scored automatically. TLS, DNS and email-authentication findings are verified by hand with independent requests and are not counted in the table above.
Why the probes are safe
Every request is benign: a lone quote and its balanced control, harmless text markers, paired true/false conditions, and bounded timing checks against a baseline. The scanner never sends OR-based or UNION SQL, never chains statements, skips delete, logout and settings forms, and never runs login brute-force or load bursts. During benchmark runs, an out-of-scope trap host confirms that no request leaves the authorized scope.