More scanners, more findings, and no clearer answer to “are we safer?”

For fifteen years the application security answer to every new risk has been another scanner. Static analysis, then dependency scanning, then containers, then infrastructure as code, then secrets, then cloud posture, then APIs. Each one was a sensible purchase. Together they produced something nobody designed: a backlog of tens of thousands of findings, a developer population that has learned to ignore it, and a board question — “are we safer than last year?” — that most security leaders cannot answer with evidence.

Three curves that crossed

Application security did not get worse at its job. Three things it depends on grew at different rates, and the gap between them is now wider than any hiring plan can close.

1. The number of known vulnerabilities

The public vulnerability record has grown almost every year for a decade. In 2024 the CVE programme published roughly 40,000 new entries, the highest annual total on record, and the National Vulnerability Database spent much of the year with a backlog of entries waiting for analysis. Every one of those CVEs is a potential line in a dependency or container scan.

2. The amount of software

Modern applications are mostly assembled, not written. A typical service pulls in hundreds of open-source packages, directly and transitively, ships in a container image with its own operating-system packages, and is deployed by infrastructure code that is itself software. AI coding assistants have accelerated the rate at which new code, and new dependencies, arrive.

3. The size of the security team

Application security teams are small relative to the engineering organisations they serve. Ratios of one AppSec engineer to a hundred or more developers are commonly reported in industry surveys, and the global shortage of security staff has been documented every year by ISC2’s workforce study. Security headcount grows linearly at best. The other two curves do not.

How the scanner estate grew

Each wave of tooling answered a real gap. The issue is what happens when they all report into different places, in different formats, with their own idea of severity.

Every addition was justified. Few estates ever removed one.

Talk to security leaders at mid-size and large organisations and the same picture recurs: eight to fifteen tools that produce findings, two or three consoles that nobody outside the security team opens, and a spreadsheet or ticket export that is the real system of record. The same vulnerable library appears in the dependency scanner, the container scanner and the SBOM tool — three findings, three tickets, one fix.

Illustrative: the same CVE in one package, reported three times.

Why more coverage produced less signal

It is tempting to read the backlog as proof that the organisation is insecure. Usually it is proof of something narrower: the findings have not been joined up. Four mechanisms account for most of the noise.

Mechanism	What it looks like	Why it matters to leadership
Duplication	The same issue from several tools, branches and rescans	Inflates every count you report and spends developer goodwill
No exploitability signal	Sorted by CVSS, where more than half of CVEs are High or Critical	The “critical” list is too long to finish, so nothing gets finished
No environment context	Test code, dev-only packages and internal services ranked like production	Remediation capacity goes to things attackers cannot reach
No ownership	Findings attached to a scanner, not a team or a service	Nobody is accountable, so SLAs are aspirational

Our own measurements make the scale concrete. On the demo estate we use for this site — two sample services, OWASP NodeGoat, a dynamic scan of OWASP Juice Shop and one AWS account — the scanners produced 382 raw results. Correlation reduced that to 287 unique findings. Adding exploitation data and environment context left 131 that we would ask a developer to act on.

The measurement trap

When the list is unmanageable, programmes drift towards measuring what they can count. Scans run, findings opened, tickets created, training completed. Every one of these goes up and to the right, which looks like progress in a quarterly review and says nothing about exposure.

The second set requires something the first does not: a defensible definition of which findings matter. That is the gap the market now calls application security posture management — a layer that sits above the scanners rather than replacing them.

What a scaling programme looks like

Programmes that have broken out of the volume trap tend to share the same structure. None of the steps is novel on its own. The difference is doing them in one place, for every kind of finding.

What the volume trap costs

The cost of noise is rarely put in a budget, because it is spread across hundreds of engineers in small amounts. It is worth estimating anyway, because it is usually the largest single cost of an application security programme and the one that tooling choices affect most.

Illustrative assumption	Value	Note
Developers receiving security findings	400	A mid-size engineering organisation
Findings routed to each developer per month	6	Before correlation and context
Minutes to read, investigate and respond to one	30	Including the ones that turn out not to matter
Share that are duplicates or not reachable	about two-thirds	In line with the funnel measured above
Developer hours a month on findings that did not need action	~800	400 × 6 × 0.5 h × 2/3

Eight hundred hours a month is roughly five full-time engineers spent on work that reduced no risk. The arithmetic is illustrative and your inputs will differ, but the structure is general: noise costs scale with the number of developers, not the number of security staff, which is why it is invisible in the security budget and very visible in engineering’s.

There is a second cost that is harder to count. Every irrelevant finding teaches developers that the next one is probably irrelevant too. When a real, exploited vulnerability arrives, it lands in a channel people have learned to skim.

Signs a programme is in the volume trap

• The headline metric only goes up. Open vulnerabilities, findings raised or scans run are reported as progress.
• Nobody can say how many findings are unique. Counts are summed across tools.
• “Critical” means CVSS 9 or above. Exploitation and exposure are not part of the definition.
• The SLA is breached by design. The number of P1s exceeds what the organisation could fix in the stated time even if it did nothing else.
• Exceptions live in email. Accepted risks have no owner, no reason on record and no expiry.
• Developers ask security which findings to ignore. The tool has lost authority, and the AppSec team has become the filter by hand.

Two or more of these usually means the next investment should be in correlation and prioritisation rather than in additional detection.

What it means at each level

Keep reading