Guest Blog

September 2026

By Sal Kimmich and Simon John

Executive Summary

In early May 2026, NHS England issued a reported internal guidance note, SDLC-8, mandating the removal of public access to several hundred GitHub repositories. The stated reason was AI-accelerated vulnerability discovery. The actual effect was to contradict years of established UK government open source policy with no public consultation, no published threat model, and no evidence the closures removed any meaningful attacker advantage.

On 14 May 2026, the Government Digital Service (GDS) and the Department for Science, Innovation and Technology (DSIT) issued guidance titled AI, Open Code and Vulnerability Risk in the Public Sector. It is a direct, technically grounded rebuttal. The guidance reaffirms open by default as the correct posture for publicly-funded code and makes it clear that closing repositories to compensate for poor security hygiene, or a misguided belief in security by obscurity is not an acceptable practice.

This brief summarizes what the guidance says, why the NHS England decision was wrong on its own terms, and what both mean for the international open source security community.

Background: What NHS England Did and Why It Matters

NHS England removed public access to repositories following vulnerabilities reported to it through Anthropic’s Project Glasswing, an initiative giving a limited set of organisations access to Claude Mythos Preview for defensive security work. AISI’s April 2026 evaluation of that model found it capable of discovering and exploiting vulnerabilities autonomously in controlled conditions. 

The community response was fast. A petition at keepthingsopen.com crossed 2,000 signatures within days. Former NHSX Head of Open Technology Terence Eden, who helped build the open source and open standards policies NHS England is now reversing, described the decision as a non-technical management overreaction to a threat briefing. He has filed a Freedom of Information request for the internal deliberations.

This matters beyond NHS England. The governance problem is structural. NHS England carries significant operational independence from Cabinet Office digital governance. GDS standards apply cross-government, but enforcement is inconsistent. The GDS response makes clear that departmental autonomy has a limit: it does not extend to contradicting settled government-wide policy without a credible technical basis.

The NHS England pattern is not a one-off. Non-technical decision-makers receiving threat briefings that focus on offensive AI capability, without equivalent context on defensive tooling and operational hygiene, will keep reaching for the same lever. Closure feels decisive. It is not a security control.

The GDS Guidance: What It Says and Why It Holds

The GDS/DSIT guidance, published 14 May 2026, does not name NHS England. It does not need to. It addresses the exact argument NHS England used and dismantles it on technical grounds. The document is structured around four recommendations and a further six points published under the heading “Additional considerations.” Both sections are worth understanding in detail. 

The Four Recommendations

GDS establishes a clear operational logic:

1. Meet a minimum standard before publishing. Named ownership, security disclosure routes, no committed secrets, automated vulnerability management, patch SLAs. This is the precondition for open publication, not a post-hoc add-on.
2. Stay open by default. Closure adds delivery cost, reduces reuse and scrutiny, and should require explicit, reviewable justification.
3. Where you do have to close access, be specific. Require a short threat model: named attacker, what source access adds to their capability, realistic harm path. Keep exceptions narrow and time-bound.
4. Invest in remediation speed. AI compresses discovery-to-exploit windows. The answer is faster patching and better dependency hygiene. Not opacity.

The Minimum Standard

GDS is explicit that the minimum standard is not a new policy. It is a clarification of what secure-by-design and open-by-default guidance always assumed teams were doing. The guidance is direct on the central point: making code private is not an appropriate mitigation for lack of ownership, patching capability, or operational assurance. If a system cannot meet the minimum standard, the correct response is to fix the system or shut it down. Using repository closure to paper over maintenance debt is the thing the guidance explicitly prohibits. That is exactly what NHS England did.

Why the AI Argument Does Not Hold

GDS acknowledges the AI threat landscape directly. It cites the AISI Frontier AI Trends Report from December 2025 and the April 2026 AISI evaluation of Claude Mythos Preview, and accepts that these tools compress the window between a weakness existing and being exploited. It does not dismiss the technology. It reframes the question.

The evidence base has broadened considerably since. AISI’s April evaluation found Mythos Preview was the first model to complete its corporate network attack simulation end-to-end, an exercise AISI estimates would take a human around twenty hours. The obvious question was whether that reflected one model or a trend. AISI answered it by evaluating an early checkpoint of OpenAI’s GPT-5.5, which reached comparable performance. Two models from different developers, both showing among the largest capability jumps AISI has recorded.

This is the correct framing. AI does not create vulnerabilities. It accelerates the discovery of vulnerabilities that already exist because of insecure architecture, poor secrets hygiene, missing patches, or weak configuration. Removing source access does not remove those underlying conditions. It removes the scrutiny that helps resolve them.

Under “Additional considerations,” GDS sets out six specific failure modes of private-by-default posture: 

• Private repositories reduce urgency to fix underlying weaknesses. 
• Code developed in the open cannot be effectively hidden because it has already been mirrored and indexed. 
• Closure becomes a one-way door that makes returning to open practice progressively more expensive. 
• Defenders can and should use the same AI tools offensively against their own codebases. 
• Openness broadens the reviewer pool across government and the supplier ecosystem. 
• Broad AI-based justifications for closure are easy to copy. Once one department normalizes this logic, it propagates.

That last point deserves emphasis. GDS is naming a contagion risk. If NHS England’s justification stands in, it will spread. Every team receiving a threat briefing will use the same rationale. The guidance removes that path by establishing a principled, technically grounded counter-argument on the record.

The strongest argument against closure as a durable control arrived after the NHS decision. In July 

2026 AISI published its first public analysis of how far open weight models trail the closed frontier. It found GLM-5.2 performing comparably to Opus 4.6 and GPT-5.3-Codex, models released four months earlier, with DeepSeek V4-Pro tracking Opus 4.5 from five months prior. Both gaps are narrower than the six to ten months AISI measured in 2025. The practical implication is direct: capabilities that today require a controlled access programme are available in downloadable weights within months, with no safeguards and no gatekeeper. A closure decision justified by what one frontier model can do has a shelf life measured in a single release cycle. The underlying weaknesses, meanwhile, persist indefinitely.

Implications for the Open Source Security Community

1. We Now Have a Government-Issued Template for Rebutting AI Closure Arguments

The GDS guidance is a credible, publicly available, government-issued document that directly refutes security-by-obscurity reasoning dressed up as an AI threat response. Open source security practitioners and policy advocates should treat it as a reference document and use it as a foundation. The core argument is portable: AI changes speed, not fundamentals. Secure design, ownership, patching velocity, and secrets hygiene are the actual controls. That argument needs to be codified in position statements and decision-support frameworks such as SSDF, SLSA, and the OpenSSF Security Baseline.

2. Defensive AI Tooling Is the Correct Investment, Not Opacity

GDS implicitly endorses using AI tools for continuous internal security review. The same tools that compress attacker discovery timelines also compress defender review timelines. That is the argument for investing in tools like OpenSSF Scorecard, OSV, Sigstore, and agentic threat modelling approaches in the SBOM and dependency review toolchain. It also cuts the other way, toward the code AI produces rather than only the code it reviews. The OpenSSF Security-Focused Guide for AI Code Assistant Instructions, a joint output of the AI/ML Security and Best Practices working groups, covers how to instruct code assistants so they account for input validation, secrets handling, dependency selection, and language-specific secure patterns. Public sector teams adopting AI assistance need that guidance as much as they need AI-assisted review, and it is available now. Governments that respond to AI-accelerated offense by closing repositories rather than building AI-accelerated defense are making the wrong tradeoff. OpenUK is positioned to make that case explicitly in UK and EU policy contexts.

3. The GDS Minimum Standard and CRA Obligations: A Partial Map

The GDS minimum standard does not cite the EU Cyber Resilience Act, and such a citation is unnecessary. The two converge on the same controls: named ownership, vulnerability reporting routes, dependency hygiene, and patch SLAs. When a voluntary UK guidance document and a binding EU regulation arrive independently at the same conclusion, that is strong evidence the requirements are the right ones. The convergence is partial rather than complete. GDS does not address the machine-readable SBOM requirement in Annex I Part II or the Article 14 reporting clock that begins on 11 September 2026, and most public sector code publication sits outside CRA scope in any case, since it is not placed on the market as a commercial product. The guidance instead cross-references the DSIT Software Security Code of Practice and NCSC implementation guidance, which are the UK’s functional equivalents. The gap that matters is not coverage. GDS guidance is guidance, the CRA is law. 

The NCSC’s June 2026 guidance on software supply chain attacks reinforces this operational picture. It identifies the complexity of modern dependency chains, automated CI/CD pipelines, and the implicit trust placed in packages and maintainers as key sources of supply-chain risk. Its response is not to make source code private. It recommends maintaining a clear inventory of dependencies, using dependency scanning, controlling how dependencies are introduced and updated, and securing the CI/CD and credential infrastructure through which software is built and distributed. The NCSC explicitly notes that this inventory can take the form of an SBOM. This is significant for the policy comparison: the UK’s own security agency is treating dependency visibility and operational controls as the response to supply-chain risk, rather than repository opacity. 

The right European comparison for the UK’s Cyber Security and Resilience Bill is not the CRA but NIS2. The Bill amends the Network and Information Systems Regulations 2018, which transposed the original NIS Directive, and NIS2 is what replaced that Directive in the EU. Both are entity-based regimes covering operators of essential services rather than product regulation covering manufacturers. Read against NIS2, the Bill shows the same parallels with the GDS guidance: timely reporting and mitigation of active exploits, rapid patching and risk management instead of hiding flaws, automated dependency tracking and vulnerability scanning, clear code ownership and responsibility for code hygiene. The Bill is not yet law. It sits before the House of Lords as HL Bill 32, with committee stage scheduled for September 2026 and Royal Assent expected before year end. Its provisions are scheduled rather than binding.

4. Other Governments Are Watching and Will Copy the Wrong Lesson

NHS England is not the only government entity that has received threat briefings emphasizing offensive AI capability. The same dynamic is playing out in technology teams across EU member states, Australia, Canada, and US federal civilian agencies. The default response for non-technical decision-makers facing that briefing, without access to GDS-quality policy infrastructure, is likely to be closure. We should track whether the GDS counter-argument propagates positively across these contexts, and produce materials that support technically grounded policy teams in other jurisdictions making the same case internally.

5. Policy Without Enforcement Is Not Enough

NHS England had open source policies. They were built during the NHSX period and embedded in internal guidance. They did not hold when non-technical management received a compelling threat briefing. That is a governance failure, not a policy content failure. The lesson is not that better policy text would have changed the outcome. The lesson is that standards for OS policies need active maintenance, periodic reassessment, and an authority with standing and willingness to enforce them. GDS reasserting itself here is a governance signal worth noting. It will not always happen. The open source security community should think carefully about what the equivalent enforcement architecture looks like at the international level.

6. The Enforcement Question Has an Answer, and It Is Not the One Anyone Expected

The technical content of the GDS minimum standard is not new. NIST SP 800-218, the Secure Software Development Framework, has covered ownership, vulnerability response, and secrets handling since version 1.1 was published in February 2022. SP 800-218A extended those practices to generative AI and dual-use foundation models in July 2024. The UK’s own DSIT and NCSC Software Security Code of Practice, fourteen voluntary principles co-sealed with the Canadian Centre for Cyber Security, covers the same territory from a different angle. A team that has done SSDF conformance work will find nothing in the GDS guidance that surprises them.

Section 5 argued that policy without enforcement is not enough. The US federal experience over the past four years is that argument in compressed form. OMB memoranda M-22-18 and M-23-16 required federal agencies to obtain software producers’ self-attestation of SSDF conformance before agencies could use their software, with CISA operating the common attestation form. The mechanism placed the burden on suppliers to produce a paper-based compliance representation, rather than creating a durable, machine-readable signal of actual security practice. Its value as an enforcement mechanism was therefore always contingent on the attestation regime itself remaining in place.  

In June 2025, Executive Order 14306 amended EO 14144 and struck the subsections directing the FAR Council to require validated attestations and artifacts from software providers. On 23 January 2026, OMB Memorandum M-26-05 rescinded both memoranda outright, stating that M-22-18 had imposed what it called unproven and burdensome software accounting processes that prioritised compliance over genuine security investments. Under M-26-05 agencies may still choose to use the attestation form and may still choose to require SBOMs, but neither is mandatory.

What did not happen is equally important to consider. The same executive order that removed the attestation mandate directed NIST to produce an updated SSDF, with a preliminary update due 1 December 2025 and a final version within 120 days. NIST published the SSDF 1.2 initial public draft on 17 December 2025. As of NIST’s most recent review of the SSDF project page in April 2026, that draft had not been finalised. The framework survived and kept developing. What disappeared was the paper-based mechanism that had attempted to turn the framework into a procurement condition for suppliers.

That is the sharper version of the point section 5 makes, and it is the one worth carrying into any jurisdiction considering how to make a minimum standard stick. Guidance is cheap to publish and cheap to keep. A compliance mechanism built around attestations is politically expensive, administratively burdensome, and ultimately reversible; its removal does not mean that the underlying security practices have lost their value. The US experience instead suggests that durable enforcement should focus on observable, operational, and preferably machine-readable evidence from the software supply chain, while keeping regulatory responsibility with the actors legally responsible for the software product. This distinction is particularly important for upstream open source projects, which are not necessarily suppliers and should not be made responsible for downstream compliance through de facto attestation or certification requirements. 

The binding lever now arriving is European. CRA Article 14 reporting obligations apply from 11 September 2026, ahead of the main provisions on 11 December 2027. From that date manufacturers of products with digital elements must notify ENISA and the relevant national CSIRT of actively exploited vulnerabilities, with an early warning inside 24 hours and a notification inside 72. Annex I Part II requires a software bill of materials in a commonly used, machine-readable format. Open source stewards sit in a distinct regime and face no penalties.  The UK Cyber Security and Resilience Bill runs parallel with 24 and 72 hour reporting duties, but the government has committed to consult on implementation during 2026, with the substance arriving through secondary legislation afterwards. It is scheduled, not settled.

The Commission has also addressed the AI question directly. Its Action Plan on Cybersecurity and Artificial Intelligence, published 7 July 2026, sets out three objectives: promoting safe and responsible use of advanced AI, reinforcing EU cybersecurity and resilience, and scaling up European AI capabilities for cybersecurity. It commits the Commission to work with ENISA on a European Blueprint for secure access to advanced AI systems for cybersecurity purposes, and to establish a secure testing platform for organisations in critical sectors including health. Most relevant here, it explicitly encourages organisations to use AI, including open source models where appropriate, to detect and address vulnerabilities more quickly. That is the same conclusion GDS reached, arrived at independently and backed by a funded programme. Two jurisdictions looking at the same capability shift, both concluding that the answer is faster defensive use rather than reduced visibility.

For practitioners doing the mapping work, two scoping notes. The Open Source Project Security Baseline already publishes a crosswalk to existing standards and frameworks across its requirement set, so the sensible move is to extend that crosswalk rather than build a new one. And configuration hardening guidance, including the CIS Benchmarks, operates at the OS layer rather than the sourcecode layer. It matters to the secure-by-design posture GDS describes and it does not map row for row against a standard built around ownership, disclosure routes, and patch velocity. Keep the layers distinct or the crosswalk stops being useful.

Recommended Actions

OpenUK recommends the following:

• Anchor the mapping work to the CRA obligations that actually bind: Article 13(5) due diligence on integrated components, the Annex I Part II vulnerability handling and SBOM requirements, and the Article 14 reporting clock from 11 September 2026. The Commission’s July 2026 CRA guidance is the interpretive layer to map against. 
• Treat the GDS guidance as a reference model for structured responses to AI-based closure arguments in government contexts. Security practitioners and policy teams should use it as a foundation for equivalent position statements in their own jurisdictions.
• Extend the existing Open Source Project Security Baseline crosswalk to cover the GDS minimum standard, retaining SSDF (NIST SP 800-218) as control vocabulary rather than as an enforcement reference, alongside the AI-specific practices in SP 800-218A and the DSIT Software Security Code of Practice. The crosswalk infrastructure already exists. The gap is UK public sector publication posture, not the underlying control mapping. Note that SSDF is under revision: version 1.2 is at initial public draft and any mapping should track it. 
• Anchor open source security positions to the GDS minimum standard framing in live UK consultations, including the implementation consultation on the Cyber Security and Resilience Bill, which the UK government has committed to run during 2026 ahead of secondary legislation. That is where the substance will be settled. 
• Develop clear public-facing guidance on AI-accelerated vulnerability discovery and open publication posture, using the GDS framing as a foundation, for use across UK and international policy contexts.
• Monitor NHS England’s response to the GDS guidance and the outcome of the pending FOI request. The internal deliberations may reveal the quality of evidence used to justify closure and strengthen future advocacy on this issue.

Sources

UK government guidance and legislation

GDS and DSIT, AI, open code and vulnerability risk in the public sector, GOV.UK, 14 May 2026. https://www.gov.uk/guidance/ai-open-code-and-vulnerability-risk-in-the-public-sector

DSIT and NCSC, Software Security Code of Practice, 7 May 2025. https://www.ncsc.gov.uk/section/software-security-code-of-practice/overview

NCSC, Software Security Code of Practice implementation guidance. https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance

Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32. https://bills.parliament.uk/bills/4035

The Network and Information Systems Regulations 2018. https://www.legislation.gov.uk/uksi/2018/506/contents

NHS England, Data Security and Protection Toolkit. https://www.dsptoolkit.nhs.uk/

AI capability evaluation

UK AI Security Institute, Frontier AI Trends Report, 18 December 2025. https://www.aisi.gov.uk/research/aisi-frontier-ai-trends-report-2025

UK AI Security Institute, Our evaluation of Claude Mythos Preview’s cyber capabilities, April 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

UK AI Security Institute, Our evaluation of OpenAI’s GPT-5.5 cyber capabilities, 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities

UK AI Security Institute, How Far Behind the Frontier are Leading Open Weight Models on Cyber?, July 2026. https://www.aisi.gov.uk/blog/how-far-behind-the-frontier-are-leading-open-weight-models-on-cyber

EU legislation and policy

Regulation (EU) 2024/2847, Cyber Resilience Act. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

European Commission, The Cyber Resilience Act: summary of the legislative text. https://digital-strategy.ec.europa.eu/en/policies/cra-summary

Directive (EU) 2022/2555, NIS2. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

European Commission, EU Action Plan on Cybersecurity and Artificial Intelligence, 7 July 2026. https://digital-strategy.ec.europa.eu/en/library/eu-action-plan-cybersecurity-and-artificial-intelligence

US frameworks and federal policy

NIST SP 800-218, Secure Software Development Framework v1.1, February 2022. https://csrc.nist.gov/pubs/sp/800/218/final

NIST SP 800-218r1 ipd, SSDF v1.2 initial public draft, 17 December 2025. https://csrc.nist.gov/News/2025/draft-ssdf-version-1-2

NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, July 2024. https://csrc.nist.gov/pubs/sp/800/218/a/final

Executive Order 14306, Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity, 6 June 2025. https://www.whitehouse.gov/presidential-actions/2025/06/sustaining-select-efforts-to-strengthen-the-nations-cybersecurity-and-amending-executive-order-13694-and-executive-order-14144/

OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, 23 January 2026. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf

OpenSSF resources

OpenSSF, Open Source Project Security Baseline. https://baseline.openssf.org/

OpenSSF, Security-Focused Guide for AI Code Assistant Instructions. https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions

OpenSSF, Concise Guide for Developing More Secure Software. https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software

OpenSSF, Concise Guide for Evaluating Open Source Software. https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software

Commentary

Terence Eden, GDS Weighs In on the NHS Decision to Retreat from Open Source, 17 May 2026. https://shkspr.mobi/blog/2026/05/gds-weighs-in-on-the-nhss-decision-to-retreat-from-open-source/

About the Authors

Sal Kimmich works on agentic runtime security at NoLabs, home of nono, the open source project that enforces per-invocation capability brokering at the kernel level so an agent never holds a credential longer than the syscall that needs it. With a decade of contributions, Sal currently co-chairs the OpenSSF BEAR Working Group, co-maintains the CHAOSS Data Science Working Group, and serves as Policy Manager and International Ambassador at OpenUK, leading CRA and NIS2 implementation work for open source. Previously Technical Community Architect at the Linux Foundation Confidential Computing Consortium. As a Co-Director of the Native American owned and founded Immersive Educational company OurWorlds, Sal runs free high school workshops on digital sovereignty and open source transparency principles using PocketBeagle boards. Across all of this work, the goal is to let people experience what it feels like to understand everything about the computing system that they rely on, because they built it themselves. 

Simon John is the Security Certification Manager at TuxCare, where he works on things like FIPS 140-3 validations and DISA STIGs for their AlmaLinux Extended Security Updates product, as well as the TuxCare Radar vulnerability scanner. You can catch him at conferences like Black Hat Europe and Infosecurity Europe chatting about FedRAMP, DORA, NIS2, SLSA, SBOM and maybe even a little about kernel LivePatching.

Simon has been using Linux for over 25 years and is an active community contributor to the AlmaLinux OS Foundation – he wrote their first CIS benchmark and sits on the Core and Certification SIGs, helping to certify hardware and software against the AlmaLinux OS.