Why most security scanners get ignored

Ask an engineering team whether they run a security scanner and the answer is almost always yes. Ask when someone last acted on its output and the room goes quiet.

This is usually diagnosed as a discipline problem. It isn’t. It’s a maths problem, and it has a threshold.

The maths of a noisy queue

Suppose your scanner reports 1,000 issues and 20 of them are real. To find those 20, a reviewer has to open, read and dismiss 980 that aren’t. At five minutes each — generous, for anything requiring you to understand the surrounding code — that’s over eighty hours of work to recover twenty findings.

No team has eighty hours. So what happens instead is entirely rational: the queue gets sampled, then skimmed, then ignored. The tool keeps running. The dashboard stays green in the sense that nobody is looking at it.

The critical insight is that the 20 real findings were never the bottleneck. The 980 false ones were. Doubling your detection rate while holding precision constant makes the problem worse, not better.

Why pattern matching plateaus here

Traditional static analysis matches shapes. It sees a string concatenated into a query and reports SQL injection. It is right about the shape and, most of the time, wrong about the consequence — because:

• The value was validated three frames up the call stack.
• The ORM parameterises it anyway.
• The route is behind an admin guard and the “attacker” is already an administrator.
• That code path is unreachable in any deployed configuration.

Each of these requires reading code the matcher never looked at. You cannot fix this by writing more rules, because the missing information isn’t in the pattern — it’s in the rest of the application.

A rule can tell you a line looks dangerous. Only context can tell you whether it is.

Raising precision means throwing work away

The uncomfortable conclusion is that a useful security tool has to spend most of its effort discarding its own output. Not ranking it, not scoring it in a severity column — deleting it, before anyone is asked to look.

That means work the tool does that you never see:

1. Reconstructing the flow, so a finding is a path from a real entry point to a real sink rather than a line number.
2. Learning the stack, so the sanitisers and guards you already have are counted as the defences they are.
3. Validating reachability, so flows that can’t happen in practice never reach the audit stage.
4. Reproducing the exploit, so a candidate has to be independently reconstructed before it earns the word “vulnerability”.

Each stage costs compute and returns nothing you can put in a marketing chart. Each one raises the only number that decides whether your tool gets read.

The number that matters

There’s exactly one metric worth optimising for a security tool: the share of reported findings that a reviewer agrees are real. Get it high enough and behaviour flips. The report stops being a queue to triage and becomes a short list to fix. People start opening it on the day it arrives.

Get it wrong and it doesn’t matter how good your detection is. You have built something that runs on every commit and protects nothing.