AI Found 100+ Flaws in UK Government Code. Is Your Code Next?

A security researcher used consumer AI models to review public UK government code and found more than 100 serious vulnerabilities, including a live credential with access to an entire agency's SharePoint. What was found, what AI changes, and why continuous code analysis matters more than ever.

• 349 public codebases reviewed across 33 organizations
• ~2/3 of them had vulnerabilities, per the researcher
• 18 months a deleted credential stayed retrievable on GitHub

Short answer: AI models can read large amounts of public code quickly and spot mistakes. That helps defenders and attackers alike. Most of the flaws found in UK government code were familiar ones: credentials in code, missing access checks, tokens shipped to the browser. The fix has not changed: scan every change, automatically, before it ships.

What the UK investigation uncovered

On Nov 10, 2026, WIRED reported that Chris Nesbitt-Smith, a researcher at the security consultancy ControlPlane, had found more than 100 serious vulnerabilities in publicly available UK government code. He scanned 349 public-sector codebases across 33 organizations and found vulnerabilities in about two-thirds of them. He used consumer-grade versions of Anthropic's Claude Opus and Sonnet models on a laptop, and said many of the issues could have been caught by a routine IT health check.

The news is from November, but the research is older. The cases ControlPlane has published were reported privately between June and August 2026, and each one was fixed before the details came out. The table below shows the dates from ControlPlane's disclosures.

Organization	What was found	Reported	Fixed
Scottish Government open data portal	A long-lived administrator API token built into the portal's public JavaScript, readable by any visitor	Jun 23, 2026	Jun 25, 2026: service taken offline for good
Department for Education, "Get help buying for schools"	Anyone with a request ID could change that request, including its contact email, without signing in	Jun 26, 2026	Jul 10, 2026
Planning Inspectorate	A live Microsoft Entra ID application credential (client ID, tenant ID and client secret) in a notebook file on GitHub	Aug 26, 2026	Aug 26, 2026: secret revoked about 20 minutes after the report

The Planning Inspectorate case was the most serious. According to ControlPlane's disclosure, the credential had tenant-wide read and write permissions. That meant access to every SharePoint site, employees' private OneDrive accounts and libraries holding evidence under legal hold for planning inquiries. ControlPlane rated it CVSS 10.0. The file had been removed from the branch, but the old commit stayed retrievable on GitHub for 18 months.

The response was fast. The Planning Inspectorate told WIRED that its monitoring detected the researcher's activity right away, that it fixed the issue within 20 minutes of the report, and that no data breach occurred.

How AI models assist vulnerability discovery

None of these weaknesses were new. What changed is the method of finding them. A language model can read a repository, explain what the code does, point to suspicious patterns and suggest how they could be abused, in minutes. One researcher with a laptop covered hundreds of codebases.

The UK government had already seen this coming. In May 2026, the Government Digital Service and DSIT published guidance on AI, open code and vulnerability risk. It notes that making code visible mostly affects how quickly a weakness is found. The weakness is there either way. It asks public code to meet a minimum standard, including that secrets are never committed to any repository, public or private, and that secret and vulnerability scanning run automatically.

The takeaway. If an AI model can find a flaw in your public code in minutes, so can an attacker. Making the code private does not fix it: private repositories can leak or be copied too.

Common weaknesses found in public repositories

1. Exposed credentials. Client secrets, API keys and tokens committed to code or config files (CWE-798). Deleting the file does not remove it from Git history.
2. Secrets sent to the browser. Tokens embedded in JavaScript are visible to every visitor who opens the developer tools.
3. Missing access checks. An ID in a request is treated as proof of permission, so anyone who knows it can act on the record (CWE-862, CWE-639).
4. Over-broad permissions. A pipeline that needs one folder gets tenant-wide read and write rights, so one leak exposes everything.

Exposed credentials deserve special attention, because one secret can open an entire environment. We will look at how to manage secrets in an upcoming article.

AI-assisted discovery vs. dedicated SAST tools

If one researcher with a consumer AI model can find more than 100 serious flaws, it is fair to ask whether an AI chat tool can replace a code security tool. It helps to look at what each one is built for. An AI model is a general assistant: it is very good at reading and explaining code when someone asks. A SAST tool is a control: it checks all of the code against defined rules, the same way, every time the code changes. The researcher had to decide to look. A control runs whether anyone remembers to look or not.

	AI chat model	DerScanner SAST
Best at	Exploring unfamiliar code, explaining a finding, ideas for a fix	Checking every file in every build against a defined rule set
Coverage	What you paste in or point it at	The whole project, every scan
Repeatability	Answers can change from run to run	Same code, same rules, same result
Accuracy	Can miss issues or describe ones that are not there	Known rules with severity, CWE mapping and triage status
Your code	Often sent to an external service	Can run inside your own network
Evidence	A chat transcript	Reports for auditors, history of new and fixed issues

The UK case makes the point. AI helped one researcher cover a lot of ground quickly, yet the flaws themselves were basic, the kind a routine check should catch. Catching basic mistakes on every change, without depending on someone deciding to look, is what SAST in the pipeline is for.

How to introduce continuous code security analysis with DerScanner

1. Start with a baseline. Scan your main repositories once to see where you stand. DerScanner's SAST supports 43 programming languages.
2. Scan every change. Run scans from your CI pipeline, so new issues are caught before merge. DerScanner integrates with GitLab CI, Jenkins, Azure DevOps and TeamCity.
3. Cut the noise. DerScanner's AI triage (DerTriage) checks each finding in context and marks it Confirmed or Rejected, with its reasoning. Your team works on the real issues.
4. Track progress. Compare each scan with the previous one to see new, remaining and fixed vulnerabilities, and export reports in PDF, HTML, CSV or SARIF.

Your code stays with you

DerScanner can run on-premises, including in closed networks, so your source code and any secrets it holds are never sent to an outside service. That matters for government and regulated teams, the same organizations this investigation covered.

Find what an AI could find, first

Book a demo and see what DerScanner finds in your own code. Get a demo

Sources: WIRED, "Security Flaws Across UK Government Sites Exposed 'God-Tier' Information," Nov 10, 2026 (wired.com); ControlPlane disclosures for the Planning Inspectorate, the Scottish Government open data portal and the Department for Education; GDS and DSIT, "AI, open code and vulnerability risk in the public sector," May 14, 2026 (gov.uk); DerScanner User Guide, release 13.