Open Source Is Not a Security Boundary

On May 14, 2026, the UK Government Digital Service published guidance on AI, open code, and vulnerability risk in the public sector. The guidance answers the right question: AI can make vulnerability discovery cheaper, but repository privacy still does not become a security boundary.¹

A public report nine days earlier said NHS England planned to make hundreds of GitHub repositories private after internal concern that AI vulnerability tools could inspect public code at scale.² The anxiety makes sense. The proposed control does not. Hiding code treats discovery as the threat. Serious security work treats unfixed weakness as the threat.

Open-source security improves when teams reduce real exposure: no secrets in code, clear exceptions, owned repositories, working disclosure paths, fast patches, and public evidence that fixes reached users. Repository privacy can support a specific exception, but it cannot replace that operating system.

TL;DR

GDS says public-sector teams should keep code open by default, review exceptions deliberately, and focus on the practical factors that change real risk.¹ That answer beats a repo-privacy panic because public code may already exist in forks, mirrors, caches, package artifacts, container images, screenshots, generated clients, and previous clones. More important, public code lets more people inspect, reuse, report, and improve it.¹³

The right response to AI vulnerability discovery is not “make everything private.” The right response is: remove secrets, classify sensitive code, publish clear exceptions, run dependency and secret scanning, maintain a vulnerability disclosure path, patch quickly, and keep evidence that the open code has an owner.¹⁴⁵

Key Takeaways

• For engineering leaders: privacy can reduce exposure in narrow cases, but it cannot replace ownership, inventory, patching, and disclosure.
• For public-sector teams: open-by-default still works when teams pair it with explicit exceptions for secrets, fraud controls, sensitive architecture, and unreleased policy.
• For security teams: AI raises the value of response capacity. A private repository with no triage path still fails.
• For agent teams: code visibility is only one attack surface. Tool permissions, state boundaries, egress controls, and release gates matter more than whether a repository looks private.
• For maintainers: publish fewer mysteries. Good documentation, clear security contact points, and small well-owned services reduce risk more than a wall of private repos.

The Panic Mistakes Visibility For Vulnerability

AI vulnerability scanners change the economics of inspection. A person used to need time, skill, and patience to search through a codebase. A capable model can inspect more code faster, connect clues across files, and produce more candidate findings. That shift increases pressure on teams that already had fragile code, vague ownership, and slow patch paths.

Repository visibility still does not equal vulnerability. Public code can reveal a bug. Private code can contain the same bug. An attacker can often infer behavior from binaries, API traffic, client bundles, package contents, container layers, logs, documentation, dependency metadata, or an old clone. GDS makes the same practical point: making a previously public repository private may not remove access for capable adversaries because popular projects often have forks or mirrors, and even low-profile repositories may already have reached researchers or attackers.¹

That caveat matters because “close it” feels like action. The action may produce less public accountability while leaving the technical weakness in place. Teams can lose outside review, shared fixes, and reuse while gaining little protection against anyone who already copied the code.

Open source also creates an audit trail. Public history shows who changed what, when a fix landed, how maintainers responded to a report, and whether a project still has active care. Private code hides those signals from peer teams, suppliers, researchers, and other public bodies that might reuse or improve the work.

Open By Default Is Not Naive

GDS does not argue that every line of code belongs on the public internet. The older GOV.UK open-source guidance already names legitimate reasons to keep code closed, including keys, credentials, fraud-detection algorithms, and unreleased policy.³ The Technology Code of Practice also pairs openness with security and privacy obligations, not against them.⁴

The stronger rule is open-by-default with specific exceptions. That policy shape forces a team to name the risk instead of using “security” as a blanket category. A secret does not belong in a repository. A fraud signal may need restricted visibility. An unreleased policy service may need a timed hold. A codebase that merely feels embarrassing does not qualify.

The UK public-sector playbook points in the same direction. It describes an expectation that government software and code should be open-source by default, developed in the open, and published under an approved license when appropriate.⁵ DWP’s open-source code publishing policy follows the same pattern: encourage publication under open licenses while protecting sensitive source code through defined controls.⁶

That distinction protects quality. Teams that code in the open tend to write better READMEs, cleaner setup instructions, clearer issue histories, and more explicit data boundaries because outsiders may read the work. GOV.UK’s guidance says publishing code can improve documentation, maintainability, data clarity, and security feedback.³ Those benefits disappear when a team responds to AI pressure by burying everything.

The Real Control Is Remediation Speed

AI changes the clock. Discovery gets faster. Report volume rises. False positives rise too. I wrote about the same capability pressure in When Your Agent Finds a Vulnerability: discovery means little without verification and repair. Teams need triage, owner routing, patching, disclosure, and release evidence. Repository privacy does not give them any of those things.

CISA’s Vulnerability Disclosure Policy platform exists for that reason. The platform gives federal civilian agencies a channel for receiving, triaging, and routing vulnerabilities that public researchers report.⁷ CISA’s coordinated vulnerability disclosure program also covers vulnerabilities across critical infrastructure, including open source software and AI systems, and emphasizes mitigation coordination before public disclosure.⁸

NCSC gives UK organizations the same operational frame through vulnerability reporting and disclosure guidance, including a toolkit and a ready-made route for government departments.⁹ The common thread is simple: accept that outsiders will find bugs, then make reporting and remediation work.

That frame turns AI vulnerability discovery from a reason to hide into a reason to improve the response loop. If a model can find a bug in your public code, the team should ask five questions:

Those answers reduce risk whether the code is open or closed. Hiding the repository only changes who can see the source today. It does not create an owner, a patch, or a disclosure path.

A Better Decision Rule

Teams need a decision rule that separates embarrassment, exposure, and genuine sensitivity.

The rule also prevents a common failure: closing everything because the team cannot classify anything. A repository inventory should answer what the service does, what data it touches, who owns it, which secrets scanners run, which dependencies matter, and how reports reach maintainers. If the team lacks those answers, the team has an operational gap. Changing repository visibility may hide the gap from the public, but the gap remains.

Agents Make The Boundary Problem Bigger

AI coding agents make the same lesson sharper. A repository boundary does not stop an agent from making an unsafe decision inside allowed permissions. I wrote about that pattern in Agent Sandbox Security Is a Suggestion: the dangerous actions often happen inside the permission set, not outside it. The same composition problem drives software supply-chain attacks, where individually reasonable pieces combine into a harmful path.

The invisible agent problem applies to open-source policy too. Teams cannot govern what they cannot see: tool paths, generated artifacts, caches, release state, disclosure queues, and owner handoffs all matter.

Open-source policy should learn from agent security. The useful boundaries live at the action and response layers:

• classify untrusted input before tools touch it;
• remove secrets from code, history, logs, packages, and generated assets;
• separate build caches and release artifacts by trust level;
• restrict outbound network paths for automated workflows;
• require evidence before publishing, deploying, or declaring a fix complete;
• give external researchers a safe, documented reporting path.

Those controls do not depend on source secrecy. They depend on teams knowing where the sensitive material lives and which actions can cause harm. If a repository contains a real secret, making it private after exposure solves the wrong problem. Rotate the secret, remove it from history where possible, invalidate old artifacts, and document the incident path. The publication boundary matters because external output needs a stronger gate than local analysis.

That is why GDS’s guidance feels right. The guidance does not deny that AI changes vulnerability discovery. It refuses the shallow conclusion. AI makes weak systems easier to inspect, so the answer should make systems easier to own, audit, report, and repair.

What I Would Do Today

A team facing AI-driven repository panic should run a 48-hour open-code review before changing defaults:

1. Inventory public repositories and map each one to an owner.
2. Run secret scanning against the current tree and git history.
3. Check whether each repository has a security contact or disclosure policy.
4. Identify fraud, abuse, live architecture, and unreleased-policy exceptions.
5. Confirm dependency update, patch release, and rollback paths.
6. Close or delay only the specific repositories that match a named exception.
7. Publish the decision rule so future teams do not repeat the panic.

That plan gives leaders a real control surface. It also creates evidence. A future reviewer can see why a repository stayed open, why another one moved private, and what work reduced actual risk.

FAQ

Does AI make public code more dangerous?

AI can make public code easier to inspect, so teams should expect more vulnerability reports and more automated probing. The danger comes from unfixed vulnerabilities, exposed secrets, and weak response loops. Public visibility can increase discovery, but privacy does not remove the underlying bug.¹

Should teams ever make repositories private?

Yes. Teams should restrict code that contains or reveals secrets, fraud controls, sensitive live architecture, unreleased policy, or other specific harms. They should document the exception and revisit it when the reason expires.³⁶

Why not close everything until the team finishes a review?

Blanket closure trades real public benefits for uncertain protection. GDS warns that previously public code may already exist in mirrors, forks, or cloned copies.¹ A short, targeted review beats an indefinite default that hides ownership problems.

What should a public repository include before a team calls it safe enough?

At minimum: no secrets, an owner, a license, clear setup notes, dependency update practice, a security contact or vulnerability disclosure path, and a release process that can ship fixes quickly.

How does this relate to AI coding agents?

Agents expand the same boundary problem. The risk rarely sits in one visible file. It sits in permissions, generated artifacts, caches, outbound requests, build state, and release authority. Good agent security and good open-source policy both require evidence at those boundaries.

References