Scanner licenses cost less than one engineer's monthly salary. The engineering time spent reviewing their output does not.
The math most teams skip
Most teams report their scanner budget as the license fee. That is the wrong number.
Here is the actual cost model:
- Alert volume: A mid-size application produces 200 to 800 findings per scan. Most scanners report at that scale by default.
- Triage time: Experienced engineers spend 8 to 20 minutes per finding to validate, look up context, and decide whether to act.
- False positive rate: Industry false positive rates for SAST tools range from 30% to 80%. You pay the triage cost for every one.
- Frequency: Scans run on every commit or nightly. The alert volume compounds weekly.
Run the numbers. A team receiving 400 findings per week, spending 12 minutes per finding, with a 60% false positive rate: that is 48 engineer-hours per week on noise. At a fully loaded rate of $150 per hour, that is $7,200 per week, or roughly $375,000 per year, in engineering time not spent shipping product.
The scanner license probably costs $40,000 a year.
What makes the false positive rate so high
Scanners work on probability. They flag anything that pattern-matches a known vulnerability class, regardless of whether a working exploit path exists.
A SAST scanner sees a SQL query built with string concatenation and fires a SQL injection finding. The input might be sanitized three layers up. The scanner cannot tell. It flags it anyway.
The same happens with:
- Dependency CVEs where the vulnerable code path is never called
- Injection patterns where all inputs are validated before the sink
- Privilege escalation findings where the execution context has no elevated rights
Validating each of these requires a human. That human has to read the code, trace the data flow, pull up the CVE, check the version constraints, and write a justification. That is the triage tax.
What proof-first scanning changes
I think the problem is definitional. Scanners are designed to find candidates, not vulnerabilities. The assumption is that humans will filter the list down to real issues.
Proof-first scanning inverts that. We built Sekura around a single constraint: every finding must come with a working proof of exploit before it surfaces. If we cannot synthesize a working exploit, the candidate does not appear in the report.
The output is different in kind, not just degree:
- Every reported finding is confirmed exploitable.
- The proof-of-exploit is attached to the finding, not reconstructed by the engineer.
- The triage question changes from "is this real?" to "when do we fix it?"
Triage time drops because the triage work is done by the platform. You spend time on remediation, not validation.
Measuring the tax in your environment
Before you can argue for a change in tooling, you need to measure what you are spending. Here is a simple framework:
sarif-cli findings export --last 30d > findings.json
jq '.runs[].results | length' findings.json
jq '[.runs[].results[] | select(.suppressions)] | length' findings.json
If you do not have a SAST CLI, ask your security team for the suppression rate from your current tool's dashboard. Any suppression rate above 20% is worth investigating.
Then estimate triage time. Ask two or three engineers to time themselves on the next five findings they review. Average it. Multiply by weekly finding volume. You will have a number worth putting in a budget conversation.
The shift that matters
Security budgets have historically been measured in licenses, headcount, and incident count. The triage tax is an indirect cost that does not appear in any of those columns.
I believe making it visible is the first step. Teams that measure it tend to make different decisions about which tools they run and how they configure them.
The proof-first approach does not eliminate all security work. It shifts where the work happens. Less time validating output. More time fixing real issues.
That is a trade worth making. See how we compare to traditional scanners at /vs/scanners/.