On 1 May the NCSC published a blog post telling UK organisations to prepare for a "patch wave": a coming surge of urgent software updates driven by AI tools that can now find vulnerabilities at a pace humans cannot match. The same week, NHS England issued internal guidance ordering nearly all its public source code repositories to be made private by 11 May, citing the same AI capability as the reason. Two responses to the same fact. Only one of them is a fix.
What the NCSC actually said
Ollie Whitehouse, the NCSC's chief technology officer, put it plainly. Every organisation has technical debt: a backlog of old code, old systems, and old assumptions that nobody got round to clearing up. AI in skilled hands can now exploit that debt "at scale and at pace." The agency expects an influx of vulnerability disclosures across all severities, with a number of them critical, and wants organisations ready to patch quickly and often.
The advice sits where you would expect it to:
- Identify your internet-facing attack surface and shrink it.
- Patch external systems first, then critical internal infrastructure.
- Turn on automatic updates everywhere they exist, including embedded devices.
- Accept that some legacy systems can't be patched into safety, and plan to replace them.
This lands against a backdrop the NCSC head Richard Horne has already described as a "full court press": nationally significant attacks happening multiple times a week, mostly driven by hostile states. The patch wave is the next phase of that pressure, not a separate event.
What the NHS did
NHS England's Guidance Note SDLC-8 says all source code repositories must now be private by default. Public ones need explicit Engineering Board approval. Teams have until 6 May to ask for an exemption, and until 11 May to convert. The stated reason is the rise of AI tools "capable of large-scale code ingestion."
Terence Eden, formerly the UK government's open source lead, has written about why this is a strange direction. The Tech Code of Practice and the NHS Service Standard both push the other way. The NHS Covid contact tracing app was published openly without incident. And the central premise, that hiding source code protects against AI-assisted vulnerability discovery, doesn't actually hold up. AI can read decompiled binaries. Vulnerability researchers have always found bugs in closed-source software. Closing the repository is a security gesture, not a security control.
The two approaches in one sentence
The NCSC is telling organisations to assume the bugs will be found faster and patch faster. The NHS is telling its teams to make the bugs harder to find. The first one scales with the threat. The second one buys, at best, a short delay against attackers who already have decompilers.
There is a kinder reading of the NHS position. If your patching pipeline is slow, hiding the code might feel like buying time. The problem is that it conditions the organisation to treat visibility as the risk, when the actual risk is the unpatched bug. Once the policy is in place, the incentive to invest in the patching pipeline weakens, because the perceived exposure has already been "managed."
What this means for a smaller business
You are not the NHS. You probably don't run public repositories of any size. But the underlying decision shows up in smaller forms all the time: a vendor who won't tell you what's in their stack, an internal system you can't see inside, a "we don't share that for security reasons" answer when you ask a basic architecture question. Obscurity is not, on its own, a control. It can be a layer on top of one. It is not a substitute.
The patch wave warning is the more useful signal. Three things worth checking before the next round of disclosures lands:
- What is on the public internet that you didn't mean to put there? A forgotten admin panel, a dev environment, a management interface on a router. Find it before someone with an AI-assisted scanner does.
- How fast can you actually patch? Not in theory. If a critical update for your VPN, your email server, or your CMS dropped tomorrow, how many hours or days would it take to land in production?
- What can't be patched at all? End-of-life appliances, abandoned plugins, hardware the vendor no longer supports. The NCSC is direct about this: some things need replacing, not fixing.
How Steelwise can help
Mapping what you've got facing the internet, working out which systems can be patched quickly and which can't, and building a sensible plan for the ones that can't, is the kind of review we run for clients. Get in touch.
Further reading
- NCSC: Prepare for a 'patch wave'
- The Register: NCSC warns of incoming patch tsunami
- The Record: British cyber agency warns of patch wave
- Terence Eden: NHS goes to war against open source