When AI writes your code, your supply chain just got a new stranger in it

For years, defenders worried about which open-source parts sat inside their software. Now an AI assistant is quietly adding parts of its own, and nobody is quite sure who owns the risk.

ThreatVectr NewsdeskAI-assistedPublished Updated · Editor: Lee Brown· 4 min read
Illustration: a modern developer's desk at dusk, two monitors glowing with abstract lines of code
Illustration made with AI. Not a photograph of the events described.
Share

Key points

  • Software supply chain security has spent five years focused on open-source components, after incidents like SolarWinds in 2020, Log4Shell in 2021, and the XZ Utils backdoor uncovered in March 2024.
  • AI coding assistants now write or suggest a growing share of production code, introducing a new source of untrusted material into the build pipeline.
  • AI tools can invent package names that don't exist, a mistake attackers are already exploiting by registering those fake names with malicious code inside.
  • Traditional software bills of materials, the ingredient lists companies keep for their software, don't record which lines an AI wrote or which prompt produced them.
  • Security teams are being asked to defend a pipeline where the author of the code is sometimes a statistical model, not a person.

For most of the last five years, "software supply chain security" meant one thing: what's inside your code?

Open-source libraries, small bundles of pre-written code that developers pull in to save time, have been the focus. Which versions are you using? And which of those libraries quietly pull in further libraries three or four layers deep, that no human on the team ever consciously chose?

That was the lesson of SolarWinds, where hackers slipped malicious code into a trusted software update in 2020 and rode it into US federal agencies. Log4Shell in 2021 showed a flaw in a tiny logging component buried inside thousands of products. XZ Utils in 2024 showed an attacker spending years posing as a helpful open-source contributor before planting a backdoor in software used across Linux systems. The risk, in every case, lived less in the code a company wrote itself and more in the code it inherited.

Now there's a new inheritance to worry about.

What actually changes when an AI writes your code?

The author of the code is no longer always a human being, and that breaks assumptions the whole security industry has been quietly leaning on.

When a developer at a bank picks a library, a person is making a choice. They can be asked why. They can be trained, told not to use anything from a given repository. When an AI coding assistant, a tool like GitHub Copilot or a similar large language model, suggests a block of code, the picking happens inside a statistical model that nobody fully understands, not even the company that built it.

The assistant might suggest a real, well-maintained library, or an outdated one with known flaws. It might, and this is already happening in the wild, invent a package name that doesn't exist at all.

That last one has a name in the security world: slopsquatting. AI assistants regularly hallucinate package names, guessing what a useful library might be called. Attackers watch for those guesses, then register the invented names on public repositories with malicious code inside. The next developer who accepts the AI's suggestion installs the malware themselves. We've been tracking this pattern since 7 July 2026, when we first covered slopsquatting as a live threat rather than a theoretical one.

Why the old paperwork doesn't cover this

Most large organisations now keep a software bill of materials, or SBOM, which is essentially an ingredient list for a piece of software. It records every open-source component, every version, every dependency. Our reporting on SBOM accuracy, including a July story on why those lists are often wrong before the ink dries, found that the gap between what companies ship and what they report is already significant before AI enters the picture.

An SBOM doesn't record that a chunk of a file was written by an AI assistant in response to a vague prompt from a junior developer. It doesn't record which model produced those lines, or what training data shaped the suggestion.

The industry built its defences around one question, what's in your code, and is now facing a second one it's barely started to answer: who, or what, put it there?

Should you worry about this as an ordinary user?

You don't need to understand build pipelines to get the practical point. The apps on your phone, the portals your bank uses, the software running your GP's booking system: more of the code inside them is being drafted by AI, checked lightly by humans, and shipped.

That's not automatically bad. But it means the promises companies make about knowing what's in their software are, for now, running behind reality. Expect more disclosures over the next year of vulnerabilities traced back to AI-suggested code. Keep your own software updated. That advice hasn't changed, and it matters more, not less.

© 2026 Threat Vectr