The introduction of the UK’s Software Security Code of Practice is a strong signal from the government that software supply chain security needs a radical upgrade.
Yet, while the Code of Practice is a commendable step forward, we’re missing a huge opportunity if businesses aren’t encouraged to operate from a zero-CVE (Common Vulnerabilities and Exposures) baseline – one of the critical controls for building a secure, resilient software supply chain.
Open-source software (OSS) underpins much of today’s digital infrastructure, from cloud services to critical public sector tools. Its ubiquity is a strength, but it also means vulnerabilities, whether accidental or malicious, are inevitable.
Removing them can be complex and time-consuming, and too often, organizations leave them in place hoping for the best. Every unchecked CVE is effectively a roll of the dice that could result in product outages – or give a bad actor the foothold they need to infiltrate systems.
VP International at Chainguard.
A recent Chainguard study that explores how deep the CVE issue runs found that on average, companies that outsourced CVE remediation saved $2.1 million annually – a figure that jumps even higher in sectors like consumer commerce, where frequent releases and microservices architectures make manual patching a constant burden.
Healthcare organizations, meanwhile, saw up to $50 million in value, with the majority of that value stemming from reduced risk.
It’s a clear sign that focusing on CVE remediation after the fact is not only inefficient – it’s expensive and reactive. With a proactive zero-CVE approach, organizations see fewer alerts, fewer firefights, fewer delays, and a fundamentally safer build environment from the start.
CVE conundrum: a flawed safety net
CVEs, by nature, force businesses into a constant game of catch-up. Teams are perpetually firefighting known vulnerabilities while the actual business of proactively securing software and fostering innovation falls behind.
The UK’s software security conversation needs to shift towards building preventative security into the very fabric of the software supply chain – not merely reacting once a breach hits.
In fact, enterprise organizations reported average annual savings of $44 million when remediating CVEs in their build environments, with a majority of that value derived from reduced risk exposure and faster innovation.
The UK’s Code of Practice underlines the importance of a developer-first approach. It calls for better transparency, stronger provenance, and clearer accountability.
But without changing the way we think about CVEs, this ambition won’t go far enough. CVEs don’t tell us how trustworthy a piece of software is; they just tell us where the known flaws were yesterday.
We must look upstream to tackle vulnerabilities before they even exist.
Proactive security, not patchwork
The key is to embrace secure-by-default, developer-friendly frameworks. Rather than relying on scanning tools and audits after the fact, we must bake security into our software and create transparent supply chains.
The UK’s push for secure-by-design products and services is exactly the right direction, but we have to ensure that this approach extends to the open-source components that underpin most software today – an area the Code of Practice touches on indirectly, but does not address in depth.
If we look at recent UK incidents – the NHS ransomware attacks or the M&S data breach – we see clear evidence of reactive security falling short.
Each incident tends to prompt a flurry of CVE scanning and patching across affected organizations, but this cycle of scramble and repair is unsustainable.
Teams scramble, stress mounts, and crucially, business suffers. This cycle isn’t sustainable. A shift is urgently needed towards proactive risk management, giving developers the tools they need to understand, control, and verify software security from day one.
We’ve seen first-hand how securing the build process, from commit to deployment, can drastically reduce vulnerability exposure. Provenance-first methods ensure every line of code is authenticated and traceable.
What the UK must do next
So, what does good look like for UK organizations adopting the new Code of Practice?
First, it means getting ahead of CVEs by investing in secure build processes that leave fewer vulnerabilities to patch. Second, it means prioritizing transparency with clear and robust Software Bills of Materials (SBOMs).
This enables developers and security teams to know exactly what’s in their software, where it comes from, and how trustworthy it is. Finally, it’s about shifting the organizational mindset from reactive patch management towards proactive vulnerability prevention.
For UK enterprises, government bodies, and SMEs alike, software security can no longer be a reactive afterthought. It must be embedded into the DNA of how we develop, deploy, and manage software – with controls like proactive vulnerability prevention and secure build pipelines at its core.
The UK has a chance to lead the world in proactive software security – but only if we move beyond patchwork fixes. By embedding secure-by-default practices, building transparent supply chains, and starting from a zero-CVE baseline, we can protect our digital future before threats become headlines and ensure the UK’s innovation engine runs on secure foundations rather than the vulnerabilities of the past.
We’ve featured the best online cybersecurity course.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
