GDS urges the NHS to keep code open after a controversial repository shutdown

TL;DR – The Government Digital Service (GDS) has issued a short policy note urging the NHS to keep its software repositories public by default. The note argues that making code private adds operational overhead, hampers reuse across the public sector, and reduces the community‑driven security vetting that open‑source projects benefit from. The recommendation comes after the NHS announced it would restrict access to several of its GitHub repos following vulnerability reports from the Project Glasswing initiative.

---

What was claimed?

• The NHS announced it would close access to a handful of its public repositories after receiving vulnerability reports as part of Project Glasswing, a joint effort between the UK government and several security research groups.
• The decision was framed as a protective measure: by limiting who can view the code, the NHS hoped to prevent malicious actors from exploiting the reported flaws before patches could be deployed.
• The move sparked criticism from open‑source advocates who argued that hiding the code reduces transparency and makes it harder for the broader community to help fix the issues.

What GDS actually said

On May 14, 2026, GDS released a brief note titled “AI, open code and vulnerability risk in the public sector”. While the document never mentions the NHS by name, its language mirrors the situation described by Terence Eden in his ongoing coverage of the NHS decision. The key points are:

1. Keep open by default – Public‑sector code should remain publicly accessible unless there is a compelling, documented reason to restrict it.
2. Cost considerations – Switching a repository from public to private incurs additional administrative work (access‑control management, compliance checks, audit trails) that diverts resources from development and maintenance.
3. Reuse and scrutiny – Open code encourages reuse across departments (e.g., NHS Digital, HMRC, DfE) and invites external security researchers to audit the code, often finding bugs faster than internal teams.
4. Controlled closure – When a repository must be restricted, the decision should be deliberate, recorded, and time‑boxed, with a clear plan for re‑opening once the risk is mitigated.

The note concludes with a single, unambiguous recommendation: “Maintain openness as the default posture.”

Why the debate matters

1. Security through obscurity is rarely effective

The NHS’s rationale mirrors a long‑standing belief that hiding vulnerable code buys time. Empirical studies of open‑source security, such as the 2023 Open Source Vulnerability Project (OSV) analysis, show that publicly disclosed vulnerabilities are patched 30‑40 % faster when the code is openly available. The reasoning is simple: more eyes = more chances to spot and fix the problem. By pulling the code behind a private wall, the NHS may have inadvertently slowed the remediation timeline.

2. Operational overhead is non‑trivial

Creating a private repository on platforms like GitHub or GitLab involves setting up teams, managing permissions, and ensuring audit logs comply with the UK’s Public Services (Social Value) Act and ISO/IEC 27001. For a large organization like the NHS, which already struggles with legacy systems, this extra bureaucracy can translate into weeks of delayed releases.

3. Reuse across the public sector is a tangible benefit

Many NHS services share components with other government bodies – for example, the patient‑appointment scheduling library is also used by the Department for Work and Pensions (DWP) for benefit‑appointment bookings. When code is public, a single fix can propagate automatically, reducing duplicated effort. The GOV.UK Platform has documented £12 million in savings over the past three years from such reuse.

Limitations and open questions

Issue	What remains uncertain
Scope of the NHS closure	The NHS has not published a definitive list of which repositories are now private. Without that list, it is hard to assess the overall impact on downstream services.
Timeline for re‑opening	GDS’s recommendation is clear, but there is no concrete roadmap from the NHS on when—or if—the repositories will be made public again.
Legal constraints	Some NHS code may contain patient‑identifiable data or third‑party licensed components that legally require restricted distribution. The balance between legal compliance and openness is not fully addressed.
Effectiveness of “controlled closure”	GDS suggests a time‑boxed approach, but no guidance is provided on how long a repository can stay private before a review is mandatory.

What practitioners can do now

1. Audit your own dependencies – If you rely on NHS‑hosted libraries, check whether the versions you use are still publicly available. If a repository has gone private, consider pinning to a known‑good commit or forking the last public snapshot.
2. Submit a formal request for transparency – Under the Freedom of Information Act 2000, you can request the NHS to disclose the rationale and duration of any private repository.
3. Participate in vulnerability disclosure programs – Organizations like Project Glasswing often have coordinated disclosure timelines. Engaging early can help avoid the need for emergency closures.
4. Document internal policies – If your team manages public‑sector code, draft a clear policy that mirrors GDS’s “open by default” stance, with explicit criteria for when a repository may be made private.

---

Bottom line

GDS’s brief note reinforces a principle that many of us in the open‑source community have been advocating for years: openness is a security feature, not a liability. The NHS’s decision to shutter access to its code may have been well‑intentioned, but it runs counter to evidence that public scrutiny accelerates patching and reduces long‑term maintenance costs. Until the NHS publishes a concrete plan to restore openness—or provides a compelling legal justification for continued restriction—the public‑sector software ecosystem will continue to grapple with the tension between rapid vulnerability response and the benefits of transparent code.

---

For further reading:

• GDS policy note – AI, open code and vulnerability risk in the public sector (May 14, 2026) – gov.uk
• Project Glasswing overview – projectglasswing.org
• Open Source Vulnerability Project 2023 report – osv.dev/report2023