If you have ever asked what is a software supply chain attack, the short answer is this: an attacker breaks into something your software depends on, instead of breaking into your software directly. The bad code then reaches you through a normal install, update or build. The idea matters to anyone who ships code, and it matters more each time a team pulls in another package, model file or plugin. Weak spots in web apps and AI systems are the subject of whitehatstoic, a software, security and AI safety practice, and supply chain risk sits right across both areas.
What is a software supply chain attack?
Your app is mostly code you did not write. A web app might have a few thousand lines of its own logic and hundreds of thousands of lines from open source packages, build tools, container images and third party services. Each of those has its own authors, its own accounts and its own release process. That chain of people and systems is the software supply chain.
A supply chain attack targets a link in that chain. The attacker does not need to find a bug in your login page. They need to get their code into a library you trust, a build server you use, or an update you install. Once it is there, you run it yourself, with your own permissions.
This is why these attacks are hard to spot. The code arrives signed by the usual process, from the usual place, under a familiar name.
How a software supply chain attack reaches production code
Take a concrete case. A developer on a small team needs to parse CSV files. They search the package registry, find a well known library, and add it. That library depends on six other packages. One of those depends on a tiny helper written years ago by a single maintainer who has since lost interest.
An attacker offers to help maintain the helper. The tired maintainer hands over publish rights. A few weeks later a new version appears with a small change: on install, it reads environment variables and sends them to a remote server. The developer never added the helper by name. They may not know it exists. But the next time the team runs an install without pinned versions, the new release lands on their laptops and in their build pipeline, where the cloud keys live.
The path has four stages, and most attacks follow it:
- Entry: the attacker gains control of a package, an account, a build step or a distribution channel.
- Release: bad code ships as a normal version or update.
- Pull: your tools fetch it automatically, often through a dependency of a dependency.
- Run: the code executes during install, build or runtime, with whatever access that step has.
The XZ Utils backdoor found in 2024 followed this pattern. A contributor using the name "Jia Tan" spent more than two years earning maintainer rights on a widely used compression project, then hid code in versions 5.6.0 and 5.6.1 that let the holder of one private key run commands on affected Linux machines through SSH. A developer, Andres Freund, caught it in March 2024 after noticing that SSH connections on the unstable branch of Debian used far more CPU than they should.
Common software supply chain attack methods: poisoned packages, typosquatting and compromised build systems
Poisoned packages
The attacker publishes bad code under a real package name. They get there by stealing a maintainer's password or token, by taking over an abandoned project, or by being handed control. Install scripts are a favorite place to hide the payload, because they run before anyone looks at the code.
Typosquatting
Typosquatting means registering names that look like popular ones: a swapped letter, a missing hyphen, a plural. A developer who types the name from memory installs the wrong package. The fake often copies the real package's code and features, with the payload added, so nothing seems off.
Compromised build systems
Here the source code stays clean and the build is changed. In the 2020 SolarWinds breach, attackers inserted code into the build process for a network monitoring product, so customers received a backdoor inside an official update. Anyone reading the public source would have seen nothing wrong.
Software supply chain attacks against AI systems: model files, datasets and plugins
AI systems add new links to the chain. A team building on a language model might download pretrained weights, a fine-tuning dataset, an embedding model and a set of plugins or tools the model can call. Each one is a dependency.
Model files. Some formats for saving models can run code when the file is loaded. A model downloaded from a public hub can therefore execute an attacker's code on your machine the moment you open it. Even safe formats carry risk in the weights themselves. The BadNets paper showed that a model can be trained to behave normally on usual inputs and misbehave when it sees a specific trigger, and it framed this as a problem in the machine learning model supply chain.
Datasets. If an attacker can change training data, they can shape the model. This overlaps with data poisoning, where a small share of crafted examples can plant a backdoor or skew results.
Plugins and tools. When a model can call outside tools, a compromised plugin can return text that steers the model, or quietly send data elsewhere. That ties supply chain risk to indirect prompt injection, where content the model reads carries instructions the user never gave.
Warning signs of a software supply chain attack
No single signal proves an attack. These are the patterns that deserve a closer look:
- A dependency gets a new maintainer and a new release within a short time.
- A minor version adds an install script, network calls or obfuscated code it never had before.
- A package name differs from a popular one by one or two characters.
- Build output changes when the source code did not.
- Servers or build machines make outbound connections to hosts nobody recognizes.
- Performance shifts with no clear cause, as with the busy SSH connections in the XZ case.
- A model file asks to run code on load, or a model gives strange answers only on certain phrases.
Defenses against a software supply chain attack: lockfiles, code signing and SBOMs
Lockfiles and pinned versions
A lockfile records the exact version and hash of every package, including the indirect ones. Commit it, and install from it in your build. A new malicious release then cannot slip in on its own. Update on purpose, look at what changed, and keep the update separate from feature work so the diff is easy to read.
Code signing
Code signing lets you confirm that a file came from a known publisher and was not changed after signing. Check signatures on packages, container images and model files where the tools support it. Signing will not help if the publisher's own build was compromised, so pair it with build controls.
Software bills of materials
A software bill of materials, or SBOM, is a list of every component in a build. When a library is reported as compromised, an SBOM answers the first question fast: does the build ship it, and where? For AI systems, extend the list to model weights, datasets and plugins.
Other habits that cut risk
- Use as few dependencies as you can. Each one removed is one less link.
- Disable install scripts by default and allow them only for packages that need them.
- Give build machines short lived credentials with narrow permissions.
- Require two factor login and scoped tokens for anyone who can publish your packages.
- Load models only in formats that do not run code, from sources you can verify.
- Limit what each AI plugin can reach to the minimum it needs. Gaps here lead to broken access control.
Frequently asked questions
How is a software supply chain attack different from a direct hack?
A direct hack targets your own systems, such as your servers or your login flow. A supply chain attack targets something you depend on, so the bad code arrives through a trusted install or update and you run it yourself.
Can open source dependencies carry a software supply chain attack?
Yes. Open source packages are a common route, through stolen maintainer accounts, abandoned projects or lookalike names. Open code can be read by anyone, but that only helps if someone actually reads the version you install.
Do model evaluations catch tampered AI models?
Not reliably. A backdoored model can act normally until it sees a hidden trigger, and the Sleeper Agents paper found that such behavior can persist through common safety training methods. Evaluations help most when they include trigger searches and are paired with checks on where the model came from.
What is the first step after discovering a software supply chain attack?
Locate every place the compromised component runs, using your lockfiles or SBOM, and stop it from spreading by pinning or removing it. Then rotate any secrets it could have read, because install and build steps often have access to keys.
Where software supply chain attack research fits in software security and AI safety
Supply chain attacks sit where two fields meet. On the software side, they push security work past your own code to every package, build step and update channel. On the AI side, they raise a harder question: how do you trust a model you did not train, built from data you did not see?
The same skills apply in both places. Map every dependency. Know who can change each one. Check what actually runs, not just what the source claims. For AI systems, add careful behavior evaluations and red teaming aimed at hidden triggers. The red team idea dates to the early 1960s, when the RAND Corporation ran simulations for the United States military with one side playing the adversary. Treat model files and plugins as code with the same scrutiny as any library. The attacks keep moving to whichever link gets the least attention, so the defense is to leave no link unwatched.
whitehatstoic
Build it right. Test it thoroughly. Keep it safe. Visit whitehatstoic.com
