UK Says Fix Systems First, Not Code Secrecy
The U.K. government published guidance rejecting the idea that public sector organizations should stop publishing source code openly to protect against AI-accelerated vulnerability discovery. The real problem, the guidance says, is operational weakness-not code visibility.
The National Cyber Security Centre's recommendations address a growing debate among technology leaders: should advances in AI-assisted code analysis force agencies to keep source code private? The answer, according to the U.K., is no.
Operational maturity matters more than secrecy
User research found that open publication slightly reduces attacker uncertainty and can accelerate analysis when combined with AI tools. But this risk becomes far more significant when organizations cannot patch vulnerabilities quickly or maintain systems effectively.
The core driver of exploitation risk is not published code itself, but the existence of weaknesses: unpatched vulnerabilities, insecure implementation, and unsafe configuration or deployment.
Stopping open publication by default would not address these root causes. Instead, the U.K. recommends setting a minimum operational standard for publicly accessible systems.
What the minimum standard requires
Systems must have a named owner, a documented maintenance plan, and a clearly identified accountable team. A defined security contact and intake process is required, with clear vulnerability reporting instructions.
Repositories must contain no secrets or sensitive operational data. Automated controls should prevent committed credentials and remove environment-specific information that could increase exploitability.
Organizations must demonstrate secure-by-design practices, including threat modeling, secure defaults, least privilege, and hardened public interfaces. Operational hygiene cannot compensate for fundamentally unsafe architecture.
Dependency update tooling, vulnerability scanning, and secret scanning must be automated. Critical and high-severity vulnerabilities need defined patching timelines. Unmaintained repositories must be clearly marked and archived, or assigned an explicit owner and patching route.
Why making code private doesn't solve the problem
Making code private is not an acceptable mitigation for gaps in ownership, patching capability, or operational assurance. Code developed in the open can remain accessible to capable adversaries through mirrors, forks, prior indexing, or earlier cloning by researchers or attackers, even after it is made private.
Private repositories can create false security by encouraging security-by-obscurity thinking and reducing the urgency to address underlying weaknesses. Closure can also become a one-way decision: private repositories reduce reuse and external scrutiny, leading to divergence between internal and external versions of the codebase and making it significantly harder to re-publish safely later.
Openness can surface issues earlier by enabling a broader set of reviewers across government and the supplier ecosystem. Closing code concentrates discovery within delivery teams and internal monitoring processes.
Agentic AI changes the risk model
Security experts point to a separate but related challenge: agentic AI systems that take actions autonomously, not just generate answers.
Identity and permissions are a starting point, but network access deserves equal attention. An agent's ability to reach the internet, download tools, connect to APIs, or execute code can be just as consequential as static permissions.
Agents designed to solve problems dynamically may pull down packages, scripts, or tools when they don't know how to complete a task natively. This creates a far more complex attack surface than permissions alone.
One of the most common failures in agentic systems is treating LLM output as trustworthy rather than untrusted input. There are clear parallels between legacy security issues from untrusted user input and new security issues from trusting LLM output. By design, agentic systems take LLM output and use it as input to the next step-meaning that output is actually input for further processing.
LLMs have safety training, though this varies by model and is primarily focused on general safety issues, not application-specific security. Organizations need to treat LLM output as equivalent to untrusted user input.
Accountability remains essential
Even when a human is supposed to be accountable for an agentic system failing, it is extremely easy for them to deflect blame to the AI. In practice, the accountable human needs to present the appearance of responsible guardrails in place for the agentic system.
If failures are frequent and significant enough to affect change, having an accountable party under pressure to improve incident response is still helpful.
The path forward for operations teams
The U.K. guidance applies existing open-by-default and secure-by-design principles to the age of AI-accelerated threats. It does not introduce new security expectations-it clarifies what operational maturity already requires.
Where exceptions to open publication are necessary, they must be explicitly defined and reviewable. Teams should identify the attacker, explain what publication adds, and outline a realistic path to harm. Exceptions should be kept narrow, time-bound, and subject to periodic re-approval.
If teams cannot meet the minimum standard, leadership must address the underlying gap by resourcing the capability-typically through shared services-or by retiring systems no longer required. No live service may exist without an explicit owner and patching pathway.
For operations professionals, the message is clear: assume shorter discovery-to-exploit windows, enforce patch SLAs, automate dependency and vulnerability management, and ensure teams can respond quickly to external reports. This applies equally whether code is open or closed.
Your membership also unlocks:
