Two clocks, running in opposite directions

Why did the two clocks separate?

Neither movement is mysterious on its own. The attacking side industrialised: a published fix is a description of the flaw it fixes, people who reverse-engineer them do so all day, and the resulting exploit is shared or sold within hours. What used to be a specialist craft became a supply chain with its own division of labour, and the median gap between disclosure and use fell to under a week.

The defending side slowed for reasons that are almost respectable. Estates grew, and every additional system is another thing to schedule. Change control matured, which is to say it acquired approvals. Availability commitments hardened, so a maintenance window that interrupts a service became something to negotiate rather than announce. Each of those is defensible in isolation and together they added days to a process that needed to lose them.

The result is not a race that defenders are losing narrowly. It is two processes operating on different units — hours against weeks — and no amount of effort inside the slower one closes a gap of that shape. Teams that understood this stopped trying to patch faster across the board and started trying to patch the right things immediately, which is a different discipline with different tools and a different argument with the business.

It also explains why the summary statistics look worse each year while individual organisations improve. The mean time to fix includes everything, and everything now includes vastly more low-consequence items than it did. An organisation that deliberately leaves quiet flaws alone in order to close the used ones within a day will show a worsening average and a better outcome, and any reporting that cannot express that difference will punish it.

Does publishing details make it worse?

The objection is thirty years old and refuses to die, which usually indicates something real underneath. It runs: an advisory describing a flaw hands attackers a map, exploitation follows publication, therefore publication causes exploitation. The correlation is genuine. The causal reading is not.

What the evidence supports is narrower. Publication compresses the timeline for everybody, and it compresses it more for attackers than defenders because building an exploit is a smaller job than deploying a fix across an estate. That is a real cost of disclosure and the argument for it survives anyway, because the alternative was tried. Withholding details does not prevent discovery; it prevents defenders knowing which of their systems are affected, and it removes the commercial pressure that makes suppliers fix anything at all.

The compromise that emerged — private notice to the supplier, a deadline, then publication regardless — is not a principled position so much as a negotiated one. Deadlines exist because suppliers who face none take years. Publication regardless exists because a deadline without consequence is a request. Neither half is comfortable, and the arrangement has produced faster fixes than any regime that preceded it.

A related complaint deserves better treatment than it usually receives. Researchers publish proof-of-concept code, and the objection that this arms people is not foolish. What it misses is who the code is actually for. Defenders use it to determine whether a description applies to their configuration, which an advisory written in the abstract rarely settles, and vendors of detection use it to write the rule that spots the attempt. Criminals capable of causing harm at scale did not need it; they had already built their own from the patch. The people genuinely disadvantaged by withholding it are the ones trying to work out whether they are affected at three in the afternoon with a maintenance window at midnight. Secrecy redistributes an advantage that the attacker already holds, and it takes it from the people who have the least time to spare and the most to lose by guessing.

Where it works badly is exactly where the last section left off: equipment with no automatic update path, no security contact and a customer base that cannot patch quickly. For those, disclosure delivers a working exploit to the world and an advisory to nobody in particular. That is an argument for changing how such products are built and sold, and it has never been an argument for silence.

The signal ranks the work, it does not do it

Worth putting the objection directly, because anybody who has run this queue will raise it. If the catalogue of confirmed exploitation is the strongest signal on offer, why has prioritising by it not settled the matter? The 2026 measurement answers plainly: roughly 26% of catalogue entries were fully remediated. Three quarters of the flaws known — publicly, by name — to be in active use were still outstanding somewhere.

That is not an argument against the signal. It is an argument about what a signal can do. Ranking work correctly does not create the hours to do it, and a queue that receives more than it discharges stays behind however well it is sorted. The catalogue tells you which twelve of the 54 matter this week; it does not tell you where the engineer comes from, it has no view on the change freeze, and it has never once shortened a maintenance window.

What is actually in the queue?

Every discussion of prioritisation assumes a list, and the list is usually the weakest part of the arrangement. A scanner reports on what it can reach and recognise. What it cannot reach — a segment it has no route into, a machine that was switched off during the sweep, a supplier-managed appliance that refuses interrogation — is silently absent, and absence in a report is indistinguishable from health.

The gap is rarely small. Organisations that reconcile a scanner inventory against purchasing records, network leases and cloud billing routinely find a tenth or more of their estate was invisible, and the invisible portion skews old, because the machines nobody remembers are the machines nobody updates. A queue built on an incomplete inventory is not merely shorter than it should be; it is systematically missing the worst entries.

Software has the same problem one level down. An application is assembled from hundreds of components nobody in the building wrote, and when a flaw appears in one of them the question — do we ship this, and where — takes days to answer in most organisations. The push for a machine-readable manifest of ingredients exists to turn that into a query, and it is being adopted at the speed of anything that creates obligations for suppliers rather than benefits.

There is a second omission that inventories rarely capture, and it costs more than the missing machines. A flaw is present in an installed component, and whether it is reachable depends on how the component is configured, what calls it, and whether the affected function is ever executed. Two organisations running identical software can face entirely different exposure, and a scanner reporting on installed versions cannot distinguish them. The result is queues padded with items that are genuinely present and genuinely unreachable, which trains people to ignore the queue.

The remedy is neither a product nor a process so much as a habit of asking one more question before scheduling work: can anything actually get to it. That question cannot be answered from a report, needs somebody who understands the system, and eliminates a substantial share of most backlogs in an afternoon. It is also the first thing dropped when a team is measured on how many findings it closes rather than on which ones it should have.

Which suggests an unglamorous ordering of work. Knowing what you run is worth more than knowing what is wrong with it, because the second is derived from the first and no amount of scanning rescues an incomplete list. Teams that spend a quarter on reconciliation before buying anything to rank findings tend to discover that the ranking problem was smaller than they thought and the inventory problem larger.