Application security in 2026: finding flaws was never the constraint

Why did finding more flaws not help?

The industry solved detection with real success. Static analysis, composition analysis, dynamic testing, secret scanning and fuzzing all became cheap, fast and available in the editor. One published dataset covers 1.6 million applications and over 141 million raw findings, which is a remarkable engineering achievement and an equally remarkable operational problem.

Repair did not follow, because it is a different kind of work. Detection is a machine reading text. Repair means understanding intent, changing behaviour, proving nothing else broke, and shipping — human work that scales with headcount rather than with compute. Making the first side a hundred times cheaper while the second stayed flat did not shrink the gap. It widened it, and the widening is what the debt statistics describe.

This is why the field's dominant metric quietly stopped being useful. A count of findings measures how hard the tooling looked, and it rises when detection improves and when code volume grows. The number that describes the state of an application is what fraction of what you found is still open, and how old that fraction is.

The vocabulary for closing that gap arrived early enough: Secrets of 'shift left' success ran in August 29, 2018. What the vocabulary underestimated was that moving a finding earlier does not make repairing it cheaper — it only makes it cheaper to decide whether to bother.

Who owns a flaw in code nobody wrote?

Every workflow for repairing a defect assumes there is somebody whose defect it is. For inherited components that assumption quietly fails, and the failure explains more of the half-life gap than any technical difficulty does.

Follow one of these tickets and the shape is familiar. It is raised against a service, so it lands with the team that maintains the service. They did not add the library; it arrived four levels down, pulled in by a framework chosen before two of them joined. They can upgrade the framework, which means a migration guide, a behaviour change in a component they use heavily, and a fortnight they were not given. So the ticket is real, the fix exists, and there is no plausible week in which anybody does it.

Compare that with a flaw in a file the team wrote. Same severity, same rating, completely different economics: an afternoon, one reviewer, done. The two items sit adjacent in a queue sorted by severity, looking identical, and one of them is thirty times more expensive than the other. Any prioritisation that ignores repair cost will keep scheduling the cheap ones and keep deferring the expensive ones, and the expensive ones are the two-thirds.

The organisations that get out of this stop treating upgrades as interruptions to product work and give them a standing allocation — a fixed share of every cycle, defended when the roadmap gets tight. It is unglamorous and it is the intervention that moves the fix rate, which is the only variable in the model that changes where the queue rests.

The alternative, which is more common than anybody admits, is to let the ownership question go unanswered and allow the age of the queue to answer it instead. That is a decision too. It is simply one that gets made by default, and reviewed only when something in it is exploited.

The code arriving faster than anyone can review it

Assistants changed the arrival rate, which is the one variable in the model above that nobody deliberately chose to move.

The measurements are consistent enough to take seriously. In one large evaluation roughly forty-five per cent of generated samples failed security testing outright, with particular classes doing much worse: cross-site scripting failed in the great majority of attempts, and log injection similarly. Repository-level studies report around 1.57 times the security findings and about 2.74 times the rate of cross-site scripting compared with human-written equivalents, alongside a tenfold rise in monthly findings across six months in the codebases studied.

The subtler result is about the people rather than the output. Developers using assistants have been observed writing less secure code while rating their own solutions as more secure than they were. Fluent, well-formatted, plausible code reads as reviewed code, and a reviewer who is nodding along is not reviewing.

None of this is an argument against the tooling, and pretending otherwise would be both futile and wrong: the productivity is real and it is not going to be given back. The argument is narrower and follows from the arithmetic. If arrivals rise and the fix rate holds, the resting level rises in proportion. An organisation that adopted assistants and left its repair capacity untouched has already decided to carry a larger backlog; it has simply not written that decision down.

What does reachability actually remove?

Composition analysis traditionally answers a question of inventory: is a vulnerable version of this library present. That question has a high yield of true-but-useless answers, because presence is not the same as exposure.

Reachability asks a harder one: can execution actually get from your code to the affected function. Most of the time it cannot. A library may be pulled in for one helper, and the vulnerable path may sit in a subsystem nothing in your application touches. Answering that turns a list of components into a much shorter list of exploitable paths — and unlike every other way of shortening a queue, it does so without lowering the standard.

That distinction is worth insisting on. Raising the severity threshold shortens the list by ignoring real problems. Reachability shortens it by removing things that were never problems in your particular build. The first buys quiet, the second buys accuracy, and only the second survives contact with an auditor.

The practical caveat is that reachability is not free and not perfect. Dynamic dispatch, reflection and configuration-driven behaviour defeat static call graphs, so the analysis is conservative and errs towards reporting. Used as a ranking signal it is excellent; used as permission to ignore everything it cannot reach, it eventually goes wrong.

There is also a question of who is allowed to act on the result. If the analysis lives inside a security team's console and developers see the unfiltered list, the noise reaches them anyway and the investment buys nothing. The value is realised at the moment the shortened list becomes the only list anybody is asked to work through, which is an organisational change wearing a technical disguise.

Debt with a deadline attached

An ageing backlog used to be an internal embarrassment with no external consequence. In Europe that is ending, and the mechanism is worth understanding because it changes what the backlog is.

The Cyber Resilience Act obliges manufacturers placing products on the European market to handle vulnerabilities across the supported lifetime and to report actively exploited ones within twenty-four hours, with those duties beginning in September 2026. Attach that to the half-life figures above and the collision is immediate: a category of flaw whose median repair time exceeds a year now sits inside a regime that expects disclosure within a day of exploitation.

The practical effect is to convert a queue into an inventory of dated liabilities, each one older than the last review that failed to notice it. A finding that is eleven months old and one that is thirteen months old are indistinguishable on a dashboard sorted by severity, and completely different under a regime that asks how long you have known.

Which suggests the reporting change that most organisations have still not made. Stop leading with a count of open findings, which rises when the tooling improves, and lead with the share older than a year, plotted over time. It cannot be improved by scanning less, it moves only when repair actually happens, and it is the number the regime is built around.

Where to start on a Monday

Three measurements, none of which needs a purchase, and all of which change the conversation more than another scanner would.

Measure your actual fix rate. Count what was open at the start of last month and what closed during it. The ratio is the number that sets everything else, and most teams have never calculated it.

Age the backlog and plot the share over a year old. One chart. It will be worse than expected and it is the only figure on the page a regulator would recognise.

Expect the first version of that chart to be wrong, and publish it anyway. Ageing a backlog accurately requires a first-seen date that many tools record badly: rescans reset timestamps, re-imported findings arrive as new, and a queue migrated between platforms usually lost its history in the move. The first chart therefore understates the problem, sometimes badly. It is still the most informative artefact the team will produce that quarter, and the arguments it triggers about which dates can be trusted are themselves worth having.

Take a sample of twenty findings and ask whether each is reachable. Not the whole queue — twenty. The proportion that turns out to be unreachable tells you how much of your team's attention is currently spent on nothing.

After those three the harder work is genuinely prioritisable: raising throughput with dedicated repair time rather than goodwill, moving triage to people whose job it is, and negotiating upgrade paths for the dependencies that supply most of the debt. An organisation that has done the first three knows whether its queue is shrinking or merely being restated, and that distinction is what the entire discipline currently turns on.