Database vendors’ CVSS scores used to bring a wry smile to my face. Here was a number, presented to one decimal place, being used to answer a question that depended rather heavily on the business concerned.
Your database might hold publicly available research data. It might hold component specifications for intercontinental ballistic missiles. The same software flaw would receive the same base score, although the people responsible would have rather different concerns about a breach.
Nor could that number tell you whether compromising your particular database would provide a route into the administrative network. The contents might be of little interest to an attacker; the opportunity to reach other systems could be considerably more valuable. Even public information needs protection against alteration and disruption.
To be fair to CVSS, this is largely a complaint about how we use it. FIRST, which maintains the framework, explicitly distinguishes base severity from risk. Environmental metrics exist precisely because context matters; version 4 also accounts for impacts on subsequent systems. The difficulty comes when we turn the vendor’s base score into a business judgement without doing the intervening work.
The warehouse problem
I understood the CISOs who pushed back. Their patching backlogs resembled the warehouse at the end of Raiders of the Lost Ark: rows of crates disappearing into the distance. Anything that helped establish an order was welcome.
It was a fair objection, particularly from the people who actually had to get the patches installed.
My concern was that, when resources are scarce, the consequences of choosing badly become more important, not less. A system that helps you process the queue is useful. But we also need some confidence that the most consequential problems are near the front.
That is why CISA’s announcement on 16 September 2026 caught my attention. It announced that its weekly Vulnerability Bulletin would end on 28 September, with the emphasis moving towards real-world factors such as exploitation and exposure rather than severity scores alone.
Its Known Exploited Vulnerabilities (KEV) catalogue, alerts and advisories will continue. CISA is changing the information it sends, not suggesting we stop paying attention.
What happens next?
The principle takes me back to an early lesson I took from NIST: consider the threat, the weakness it could exploit, and what would happen as a result. Its formal definition of risk connects the likelihood of an adverse event with the harm it could cause.
The idea is hardly modern, but it remains rather useful.
For an adversarial threat, that means thinking about a credible attacker: their capabilities, objectives and opportunities. It does not require knowing their name. It does require going beyond the observation that a piece of software contains a flaw.
Consider our database again. “A vulnerability permits unauthorised access” describes a technical problem. “An attacker could exploit our exposed service, obtain privileged credentials and interrupt order fulfilment” describes a scenario the business can assess. Its likelihood still needs examination, but we now know what we are discussing.
Dave Chismon’s NCSC article, “Products on your perimeter considered harmful (until proven otherwise)”, is a useful reminder here. Writing in 2024, he described how improvements in endpoint security had helped push attackers back towards internet-facing products, including VPNs, firewalls and file-transfer services.
His distinction between putting data at risk and giving an attacker a foothold in the network is particularly relevant to our database. It is worth asking not only what a system contains, but what its compromise would make possible.
The broader lesson, for me, is that our priorities need to move with the threats. A sensible allocation of effort a few years ago may deserve another look today. That need not mean abandoning what works; it means checking that we are still spending our attention in the right places.
Keep the ordinary work moving
In plenty of areas, I would suggest no change of course at all. Automatic updates should continue automatically. Risk-based prioritisation should not turn every routine patch into a meeting.
The NCSC’s update-by-default guidance makes this point clearly: apply updates promptly and, ideally, automatically. Sensible testing and rollback arrangements still matter, as do genuine exceptions for safety-critical systems and operational technology. But exceptions should remain exceptions, with an owner, an explanation and a review date.
There is another practical reason to keep updating: vendors sometimes fix security weaknesses without publishing a separate vulnerability advisory. Waiting for an alarming score can therefore mean missing useful fixes altogether.
The place for additional judgement is where work cannot be automated, operational constraints require a decision, or new information means something needs doing much sooner.
When an alert needs action
Alerting services remain useful. The NCSC explicitly recommends monitoring vulnerability feeds, including vendor notices and CISA’s exploitation information. The window for responding to a newly disclosed vulnerability can be very short; attacks may already be under way by the time a warning arrives.
Checking whether vulnerabilities being exploited in the wild are present in our own estate is a basic defensive requirement. We need to connect the alert to the affected systems, establish their exposure and give someone responsibility for the response. Internet-facing services deserve particular urgency, without overlooking internal systems an intruder could reach.
We should not hold up an urgent response while we assemble a complete risk assessment. As Ollie Whitehouse’s guidance on preparing for a vulnerability patch wave makes clear, active exploitation can require us to accelerate the normal update process. We should agree that route with the people running the systems before we need it.
Equally, “not yet in the KEV catalogue” does not mean “safe to leave”. A catalogue of known exploitation cannot include attacks nobody has detected or reported. Credible vendor warnings should not have to wait for a second announcement.
And when an exposed system may already have been attacked, the response needs to include checking for compromise. Installing a patch does not, by itself, remove an attacker who got in beforehand.
For anyone relying on the retiring weekly bulletin, CISA’s practical advice is to switch their subscriptions to KEV catalogue updates and cybersecurity advisories, and consult relevant vendors directly.
A better discussion
For security leaders, I would make the prioritisation discussion start with a few questions. Which important service or information is at stake? Can an attacker reach the weakness? What could they do next? What have we checked, and what are we assuming?
Then ask which intervention would most effectively reduce the risk. Patching may be the answer. Restricting exposure, removing excessive privileges or breaking a route into another system may also deserve attention. The objective is to prevent the damaging outcome, not simply to close the finding.
I would rather see a board discussion about which credible routes to serious harm have been closed than simply how many vulnerabilities have been patched. Counts can support that discussion. They should not substitute for it.
The warehouse may never be empty. The useful question is whether we are dealing with the dangerous crates first.