GDS Pushes Back on NHS’s Open‑Source Retreat – A Critical Look

In the UK civil service, being invited to a meeting “without biscuits” is a shorthand for a cold, no‑frills discussion. It’s a phrase that usually stays within the walls of a department, but this month it leaked into the public sphere when NHS England announced the abrupt closure of almost 200 open‑source repositories. The move, framed as a safeguard against AI‑driven code‑exploitation, sparked a petition that quickly gathered over 2,000 signatures and set off alarm bells across government.

The GDS response

The Digital Service’s Whitechapel team released a guidance document titled “AI, open code and vulnerability risk in the public sector.” The tone is unapologetically blunt: the NHS decision is portrayed as a knee‑jerk reaction that fails to address the real security challenges. Key excerpts include:

• “Non‑technical managers need to stop over‑reacting.”
• “Closing code doesn’t solve the underlying problems. Making a repository private is not an appropriate mitigation for lack of ownership, patching capability, or operational assurance.”
• “If you are so concerned about the poor security of your systems, you should shut them down completely to mitigate the threat.”

The guidance repeatedly stresses that security is a shared responsibility and that open‑source development has historically produced higher‑quality, more secure software. Hiding code, the document argues, is akin to “papering over structural cracks.”

Why the backlash matters

Community sentiment

Developers across the NHS, other health‑tech teams, and the broader open‑source community have expressed disappointment and frustration. Many point to the fact that once a repository is public, it is often forked or mirrored; making it private later does not erase copies that may already be in the wild. A friend of the author even archived the NHS repos before they vanished, demonstrating how quickly the code can be preserved despite official attempts to hide it.

Adoption signals

The incident highlights a growing tension between AI‑enabled vulnerability scanners and traditional open‑source practices. While AI tools can surface potential flaws, they also fuel fear among managers who lack a deep technical background. The GDS guidance attempts to re‑anchor the conversation on secure‑by‑design development, proper ownership, and robust patching processes—rather than on repository visibility alone.

Counter‑arguments

Some officials argue that private repositories provide a “false sense of security” but still see value in limiting exposure while they assess risk. They claim that the NHS’s move is a temporary containment measure while a more thorough review is conducted. Critics of the GDS stance warn that blanket statements may overlook legitimate concerns about supply‑chain attacks that could be amplified when code is widely accessible.

The broader pattern

The episode is not isolated. Over the past year, several public‑sector bodies have considered—or enacted—similar restrictions after media reports linked AI code‑analysis tools to potential exploits. The pattern suggests a reactive governance model where uncertainty triggers sweeping policy changes rather than measured, evidence‑based adjustments.

GDS’s historical role was to act as a technical authority, offering Service Assessments that ensured departments could design, launch, and maintain complex IT projects. As more ministries develop internal capability, GDS’s influence has waned, but moments like this revive the debate over whether a central body should retain veto power over departmental tech decisions.

What could happen next?

1. Policy revision – The Department of Health and Social Care (DHSC) may commission a review of the NHS’s open‑source policy, potentially aligning it with GDS’s recommendations.
2. Technical remediation – Rather than hiding code, the NHS could invest in automated security testing pipelines, threat‑modeling workshops, and dedicated security teams.
3. Community engagement – Re‑opening the repositories with clear contribution guidelines and a transparent vulnerability disclosure process could rebuild trust.
4. Legislative oversight – If the controversy escalates, parliamentary committees might examine the balance between AI‑driven risk management and open‑source principles.

Bottom line

The NHS’s decision to shutter public repositories was a symptomatic response to AI‑related anxiety, not a solution to the underlying security gaps. GDS’s guidance reminds us that visibility, peer review, and collaborative improvement remain vital defenses, even in an era of sophisticated AI tools. Whether the civil service will heed that advice—or double down on secrecy—will shape the future of public‑sector software development in the UK.