Exploitability is the only triage that survives a patch wave

On May 1st, the NCSC's CTO Ollie Whitehouse published a short blog post with a thesis worth taking seriously. AI in capable hands has lowered the cost of finding bugs in legacy code, and the technical debt across open source, commercial, SaaS, and proprietary systems is enormous. The NCSC therefore expects a "patch wave": not a single CVE event, but a sustained step-change in the rate at which serious vulnerabilities surface across the stack. Their advice is to harden patching now. Prioritise the perimeter, replace end-of-life kit, and switch on automatic updates wherever operational risk allows.

The advice is sound. We want to extend it.

The NCSC piece focuses on the outer problem: what gets patched first when you can only patch some things, with the answer being internet-facing assets. The harder problem the wave will surface is the inner one: how do you triage what is left? Inside any modern codebase, the dependency tree is deep enough that a busy week of CVEs produces dozens of "criticals" simultaneously. Once that happens, the ranking system most teams currently use stops working. This piece is about why, and what to use instead.

Why CVSS-based triage breaks under wave conditions

Whitehouse points readers toward SSVC, the Stakeholder-Specific Vulnerability Categorisation system. SSVC is a useful step away from raw CVSS, because it asks whether a working exploit exists and whether the affected asset is mission-critical. We would push the same logic one step further. Under wave conditions, even SSVC-grade prioritisation hits the same wall CVSS does: when volume saturates the top bucket, any sort key built on severity-adjacent signals stops discriminating.

CVSS itself is a "could" measure: worst-case impact computed without knowing your environment. In a low-volume world, five criticals a month with ten engineers on the rota, that imprecision costs nothing. You patch all five regardless of order, and CVSS just tells you which one to start with on Monday morning.

Now picture the bad week. Forty critical CVEs land between Monday and Friday across your direct dependencies, your container images, your transitive modules, and two of your SaaS providers. You cannot patch forty criticals in a week, and probably not in a month. Each one carries a regression risk, a deployment window, on-call exposure, and a chance of breaking something downstream. Sustained patching capacity in a healthy team is closer to ten a week before other work suffers.

CVSS now offers you no signal. Every item in the queue reads "critical." The sort key has collapsed to a single value, which is mathematically equivalent to having no sort key at all. You are picking patches in roughly the order the tickets were filed, with more anxiety.

The cleanest analogy is emergency room triage during a mass casualty event. Normal triage sorts patients by acuity. After a thirty-vehicle pileup, everyone is acute, and acuity stops discriminating. Emergency departments switch protocols, and the sort key changes: not "how sick" but "where does intervention actually change the outcome?" Patients who will survive without immediate care, and those who will die regardless, are both deprioritised. The middle band, where treatment is decisive, gets first attention. Triage did not disappear under volume; the sort key changed to one that still discriminated when the old one stopped.

From severity to exploitability

NCSC's perimeter-first principle answers "what is actually exposed?" at the asset level. Exploitability asks the same question one layer deeper, at the code level: what is actually weaponizable inside the assets we have already prioritised? Once you have decided internet-facing systems matter most, the next question is which CVEs against those systems matter most, and that is where exploitability becomes the sort key.

Concretely, sort by exploitability rather than severity. The question is no longer "how bad could this CVE be in the worst case?" but "is this CVE actually weaponizable against the version of my stack that runs in production, right now?"

Exploitability is a harder question, because it has more inputs. It depends on whether the vulnerable function sits on a code path your application executes (reachability, in the strict sense), the service's network exposure, the authentication and controls in front of it, whether a working exploit exists in the wild and is actively being used, and whether the version you ship falls inside the affected range. The payoff is that exploitability discriminates. Re-ranking a hundred "critical" CVEs by exploitability typically leaves ten or fifteen genuinely exploitable in your stack, with the rest present in your dependency tree but not weaponizable from any path you ship.

That is the move. Trade a question with a known easy answer (CVSS) for one with a harder but more useful answer (exploitability). The harder answer produces a small enough actionable queue that your patching capacity has a chance of clearing it.

What Log4Shell already showed us

NCSC's piece closes with a recommendation that larger organisations gain assurance from their supply chains, commercial and open source, ahead of the wave. Log4Shell is the cleanest case study for why that recommendation matters at the code level. We are not going to retell the incident, because that post has been written enough times. The relevant detail is what happened in the first week.

Organisations spent days running grep -r log4j across their estates and finding the library buried four and five layers deep in dependency trees they had never fully enumerated. Most instances were not reachable from the internet. A meaningful fraction sat in test scaffolding that never ran in production. The teams that patched everything indiscriminately took weeks. The teams that patched what was actually exploitable from external request paths first were materially safer within forty-eight hours, with the rest cleaned up over the following month.

Log4Shell was a single CVE. The wave NCSC is forecasting will produce that pattern repeatedly, sometimes against multiple unrelated dependencies in the same week. The teams that built supply chain visibility and exploitability tooling after Log4Shell are about to be glad they did.

The honest trade-offs

Exploitability analysis is not free, and we should be straight about what it costs.

It requires inputs most organisations do not currently combine: call-graph analysis or runtime instrumentation for code-level reachability, current threat intelligence on weaponised exploits, and SBOM coverage that goes deep into the transitive dependency tree where most vulnerabilities live. It requires keeping that data current as your code and the threat landscape move. None of this is impossible, and the tooling is improving, but it is more expensive than running a CVE scanner against a manifest and sorting by severity.

There are also classes of vulnerability where exploitability analysis is unreliable or unhelpful. Cryptographic weaknesses, supply chain compromises where the malicious code is the new code, and vulnerabilities in always-on perimeter services should not be deprioritised because static analysis says the function is unreachable. NCSC's perimeter-first guidance still applies. Exploitability supplements it; it does not replace it.

What changes Monday morning

NCSC's strongest operational recommendation is an "update by default" policy. Under wave conditions, that policy is only achievable if your actionable queue is small enough that "by default" is realistic. Capacity alone will not get you there. Exploitability triage is what shrinks the queue to a size where update-by-default works in practice. Three things shift in how you operate.

The patching SLA stops being a single number tied to severity. "Criticals in seven days" is reasonable at low volume and fictional at high volume. Replace it with three thresholds: exploitable-and-actively-exploited gets emergency change windows, exploitable-but-not-yet-weaponised gets the standard cycle, and not-exploitable-in-your-stack goes onto a long tail you clear opportunistically. Board reporting will need to change to match, because executives will ask why you have eighty open criticals and you will need a defensible answer.

Dashboards and queues need to surface exploitability as a first-class field, not buried three clicks deep. Engineers triaging at 2am should see it on the same line as severity. If your tooling does not expose this, that is a procurement conversation worth having before the wave, not during it.

The negotiation with engineering changes too. Security currently brings a list of CVEs and asks for fixes; engineering pushes back on cost. Exploitability shortens the list and makes the items defensible. Engineering trusts the queue more once they have seen the non-exploitable items pruned.

The reframe

NCSC's argument is that the patch wave will overwhelm patching cadences. We agree, and we would add that it will overwhelm patching priorities first. Severity-based triage will stop discriminating before patching capacity runs out. The queue will collapse weeks before the team does.

The teams that handle the wave best will not be the ones who patch fastest. They will be the ones who decide most accurately what to patch, and what to leave alone, in environments where everything is rated critical and most of it does not matter.

The argument above maps onto what we build. Trace-AI is our software supply chain security platform. It scans your dependencies across your environment and CI pipelines, prioritises findings by exploitability, and surfaces them on the kind of exploitability-aware dashboard your team can actually triage from. More writing on patching, supply chain, and AI safety at zerberus.ai/blog.