There Will Be Bugs: How the NCSC Is Trying to Eradicate an Entire Class of Vulnerabilities

Danny Bradbury asks whether an ambitious new UK government initiative will lead to more secure software

In the fight for more secure software, developers face a rising torrent of bugs. All of them are bad, but some are far worse than others. How do they decide which is which? In January, the UK’s National Cyber Security Centre (NCSC) published a paper that it hopes will help developers surface the worst ones and encourage a fix.

The question is, can it overcome an age-old vendor preference for time-to-market over security?

Slash and burn

The NCSC’s paper aims to help developers navigate the go-to system for cataloguing bugs: MITRE’s Common Vulnerability Exposure (CVE) system, which it runs on behalf of the US Cybersecurity and Infrastructure Security Agency (CISA). The catalogue is growing quickly: 2024 saw MITRE add over 40,000 records – each describing a software bug – to that database. That’s up over 38% year-on-year. In 2002, when US agencies first started using MITRE’s system, the annual vulnerability count was just 1,961.

The NCSC seeks to highlight the software flaws that are both ubiquitous and easy to fix. To do that, its paper divides them into two types: forgivable and unforgivable. A forgivable bug, it says, is subtle, with not a lot of information about it. The cost to fix it is high, and relies on complex prerequisites. Conversely, an unforgivable bug is cheap to fix, without too many prerequisites – and information on how to do is easy to find. Fixing it is, in short, a no-brainer, and it should never have been there in the first place.

“This idea of vanquishing software bugs like a kind of digital smallpox is appealing.”

The key goal for the NCSC is to make the process quantifiable. To do so, it began by looking at the CWE top 25. This is MITRE’s list of the most common software vulnerability types, like cross-site request forgeries or improper input validating. Each of these turn up in large numbers of CVEs.

The NCSC identified the top-level fixes required for the CWE vulnerabilities. For each fix, its researchers evaluated three factors: how much it costs, how widely understood it is, and its technical feasibility. Each of these factors gets a score between one and three, which are added together to produce a final score for the fix.

It can then assess individual CVEs by identifying the top-level mitigations that must be applied to fix it, and viewing all of their scores. Any with “easy” fixes are declared unforgivable. The hope is that researchers, developers and software vendors will adopt this method to target those flaws, slashing and burning a forest of vulnerabilities.

What causes ‘unforgivable’ mistakes?

Tim Mackey, head of software supply chain risk strategy at Black Duck, likes the idea of stamping out foundational bugs.

“I’m a huge proponent of the CWE model, and saying, ‘can we as an organisation choose one of these weaknesses and find a way to burn it to zero?’ And then once [it’s at] zero, we should never see that again,” he tells Assured Intelligence.

This idea of vanquishing software bugs like a kind of digital smallpox is appealing, but it hasn’t happened yet. Why not? Black Duck CISO, Bruce Jenkins, puts it down to an obsession with margins and profitability. Companies want to get to market as soon as possible, which often means taking short cuts, he warns. The NCSC has cited the same challenges, hence its latest initiative.

Yet while we mull incentives for vendors to do the right thing, customers shoulder the cost, warns Gregory Touhill, director of the CERT Division at Carnegie Mellon University Software Engineering Institute.

“Given the competitive landscape, it’s a difficult thing to push on everybody.”Jay Jacobs

“Maybe we need to take a page out of Jen Easterly’s handbook,” says Touhill, who was the first CISO of the US government under the Obama administration.

“I think Jen was right that we need to balance that discussion on liability back towards the manufacturers as the final assembly point [for software], because they are in the best position to reduce the amount of vulnerabilities,” he tells Assured Intelligence.

In the US, CISA’s rhetoric hasn’t resulted in any regulations against software vendors. And with a new government hell-bent on deregulation, it seems unlikely in the short term. In any case, not everyone is happy about the idea of punitive regulations.

“I would be nervous about that, and I think a lot of organisations would be too, because of our level of maturity and understanding of exactly how to fix it,” says Jay Jacobs, founder of Empirical Security. “Given the competitive landscape, it’s a difficult thing to push on everybody.”

In the meantime, he hopes that the threat of regulation might be enough. “Vendor motivation to put more effort into security is low, but I do think that they will have motivation to avoid being in a heavily regulated industry,” he tells Assured Intelligence.

“The fact that a vulnerability is complex or costly to fix doesn’t mean it’s okay to leave it in place.”Bruce Jenkins

However, the EU has taken firmer action with the Cyber Resilience Act (CRA), which it adopted in October 2024. Its provisions, which become applicable in December 2027, include baking cybersecurity measures into digital products at the design and development stage, reporting actively exploited vulnerabilities to regulators within 24 hours, and implementing vulnerability management practices. Vendors failing to do so will face fines of up to €15m (£13m) or 2.5% of their global revenue.

Nudging the needle

While we work out how to get vendors to pay attention to frameworks like the NCSC’s, Touhill’s colleague Allen Householder, a senior vulnerability researcher in the CERT Division, still has misgivings. He lauds the NCSC for launching the initiative, but worries that the two simple categories “forgivable” and “unforgivable” don’t provide sufficient context for a bug.

“A vulnerability might be marked as unforgivable, but if it’s buried deep inside a system and not exposed in any meaningful way, is it really more dangerous than a forgivable one that’s actively being exploited? That’s the kind of question that needs to be asked,” he tells Assured Intelligence.

Black Duck’s Jenkins feels that vulnerabilities should be evaluated based on the risk they pose rather than whether they were difficult to prevent or remediate.

“The fact that a vulnerability is complex or costly to fix doesn’t mean it’s okay to leave it in place. If it’s a serious enough risk, then it should be addressed, no matter how difficult or expensive that process is,” he argues.

The NCSC is mulling risk context on a list of potential future research topics. This could include the role of a product and the severity of the vulnerability, along with determining the vendor or developer’s vulnerability management maturity. Is being unaware of a vulnerability later exploited in the world unforgivable, it asks? All of these questions are up for debate in what is clearly an evolving discussion about how best to tackle software bugs.

As Carnegie Mellon’s Touhill notes, we’ve been having this discussion for decades. Vulnerabilities will never disappear entirely. So what can we do to combat imperfections in vendors’ software products? The NCSC has some ideas. In February 2024 it released its vulnerability management guidelines, with several core principles:

• Identify your assets
• Apply updates by default as soon as possible
• Triage and prioritise what you fix
• Consider the risks of not updating in a wider business context
• Regularly review your vulnerability management process

In the meantime, Empirical Security’s Jacobs and other experts hope that efforts by the likes of the NCSC can nudge the needle. Anything that stops the onslaught of bugs – especially the facepalm-inducing variety – from endangering organisations and their customers, can only be a good thing.