The triage tax
Ask any team that has wired a scanner into CI what happened next: a wall of findings, most of them noise, and a weekly meeting where engineers argue about which ones are real. The scanner was supposed to save time. Instead it created a triage tax, and after a few sprints people stop reading the reports. That is how real vulnerabilities ship inside ignored dashboards.
Confirmation before reporting
Our security engine takes a different position: a finding is not worth your attention until it comes with proof. The attack-confirmation layer attempts to verify each candidate finding with a benign probe, and only confirmed results are promoted. Each confirmed result carries an evidence bundle: the exact request, the response, and what the response demonstrates.
For a manager, this changes the economics of security review. The question in the room stops being "is this real?" and becomes "when do we fix it?", which is a planning question instead of a forensics session.
What to demand from any scanner
- Evidence attached to every finding: request, response and proof, not just a CWE number.
- A confirmed/unconfirmed split so triage effort goes where it matters.
- Exportable evidence your auditors and customers can read without a security background.
How we measured this
- A finding is marked confirmed only when the verification replay reproduces the behaviour with a benign payload. The request and response of that replay are stored with the finding and shown in its evidence bundle.
- Observations that were not reproduced stay labelled unconfirmed and never fail a pipeline gate.