The main types of software supply chain attacks are poisoned updates, hijacked maintainer accounts, fake lookalike packages, tampered build systems, compromised tools or plugins, and attacks on the places software is stored and shared. In each one, the attacker reaches you through something you already trust.
TL;DR
- A software supply chain attack hides bad code inside something you were going to use anyway.
- There are six common doors: a trusted update, a maintainer account, a lookalike package, a build system, a helper tool, and a shared storage place.
- You cannot stop every door from the outside. You can know what you use, slow down risky changes, and notice trouble early.
Definition: A software supply chain attack is an attack on the parts, people or tools that go into making software, instead of an attack on the finished software itself. The "supply chain" is everything between an idea in a developer's head and the program running on a customer's machine.
What is a software supply chain, in everyday terms?
Think about a restaurant. The kitchen does not grow every ingredient. It buys flour from one company, eggs from another, and sauces from a third. If a supplier ships a spoiled batch, the restaurant can make people sick without anyone in the kitchen doing anything wrong.
Software works the same way. Almost no team writes everything from scratch. They use small ready-made building blocks called packages or libraries, which are bundles of code written by other people, usually shared for free. A modern app can use hundreds of them. Each block can in turn use other blocks, which we call dependencies (a dependency is any outside piece of code your software needs in order to run).
On top of the blocks sit tools: the editor where code is written, the build system that turns code into a finished program, and the pipeline that tests and ships it. Every one of these is a link in the chain. An attacker only needs to break one link.
If you want a longer introduction, our post what is a software supply chain attack covers the basics. This post is a map of the different ways it happens.
What are the six common types of attack?
Here is the whole map in one table. After it, we walk through each row.
| Type | The attacker's trick | A kitchen comparison |
|---|---|---|
| Poisoned update | Slips bad code into a real, signed product update | A trusted supplier's delivery is tampered with before it arrives |
| Account takeover | Steals or buys the access of someone who publishes a package | Someone steals the delivery driver's keys |
| Lookalike package | Publishes a fake with a name close to a real one | A box labeled "Flour" next to the box labeled "Flower" |
| Build system tampering | Changes code during the step that assembles the product | A saboteur inside the factory, after inspection |
| Helper tool compromise | Breaks a plugin, script or action your pipeline uses | The oven's remote control is hacked |
| Storage and sharing attack | Poisons a registry, mirror or container image | The warehouse shelf is restocked with bad goods |
Poisoned updates
In a poisoned update, attackers get their code into a legitimate update that customers install willingly. A well known case is the SolarWinds incident. The US Cybersecurity and Infrastructure Security Agency (CISA) described it in an advisory: a supply chain compromise of a library file in certain SolarWinds Orion products was one way the attackers got in, with the activity starting in at least March 2020. Customers did what they were supposed to do, which was install an update.
Account takeover
Open source packages are often looked after by one volunteer. If an attacker gets that person's login, they can publish a new version that looks completely normal. This is why registries push two-factor authentication, which asks for a second proof of identity, such as a code from a phone app or a security key. The npm documentation says that publishing requires either two-factor authentication on the account or a special token that bypasses it. We explain the details in compromised maintainer accounts on npm.
A closely related risk is malicious code appearing in a trusted project. CISA reported in March 2024 that malicious code had been found in XZ Utils versions 5.6.0 and 5.6.1, a data compression library that can be present in Linux distributions. It was tracked as CVE-2024-3094, and CISA advised downgrading to an uncompromised version such as 5.4.6.
Lookalike packages
Typosquatting means publishing a package whose name is one typo away from a popular one, hoping a busy developer mistypes it. Dependency confusion is a cousin: the attacker publishes a public package with the same name as a company's private one, hoping the build system grabs the wrong one. See anatomy of a typosquatting campaign and dependency confusion attacks explained for more.
Build system tampering
A build system is the machine or service that turns source code into the program people install. If an attacker controls it, they can add code after the humans have reviewed everything. The review looked fine, because the review never saw the change. The SLSA project, a set of supply chain guidelines, makes this point directly: code can change at any link from source to build to distribution, so the program you run may not be the code that you scanned.
Helper tool compromise
Pipelines run helper scripts, plugins and prebuilt steps. GitHub's own hardening guide advises pinning an action to a full-length commit identifier, because that makes it much harder for someone to slip a backdoor into the version you use. If you use a tag instead, GitHub says to be sure you trust the creator. Our GitHub Actions hardening checklist goes step by step.
Storage and sharing attacks
Registries are public warehouses where packages and container images are stored. If an attacker can place a bad item on the shelf, or make a bad item look like a good one, everyone who pulls from that shelf is at risk.
Which type should a small team worry about first?
Not all six doors are equally open for every team. A rough guide:
- Lookalike packages are the easiest for attackers to try, because anyone can publish. They hit teams that add packages quickly.
- Helper tools matter if you use shared pipeline steps from outside your company.
- Account takeover matters most if you publish packages yourself.
- Build system tampering matters more as you grow and ship software to customers.
- Poisoned updates are the hardest to prevent, so detection and fast response matter most.
What does this look like with real numbers?
Here is a worked example. These numbers are invented to show the idea. They are not from a real company.
A small team ships a web app. Their list of dependencies, the full count including blocks used by other blocks, is 640 packages. They add 4 new packages in an average month, and 90 of the 640 get a new version in that same month.
- New packages per month: 4. Each one is a chance for a lookalike mistake. Rule: a second person checks the name and the publisher before it goes in.
- Updated packages per month: 90. Each one is a chance for a poisoned update. Rule: wait a few days before taking brand new versions, unless it is an urgent security fix.
- Pipeline helper steps: 12. Each one is a chance for a helper compromise. Rule: pin all 12 to a full commit identifier.
None of these rules stops a determined attacker. Together they turn a wide open door into a series of small speed bumps, and they give the team a short list of things to look at when news breaks. That last part is the real prize. When a story like XZ Utils hits the news, the first question is always "do we use it?" A team that already has an up to date list can answer in minutes.
How can you reduce the risk without a security team?
Start with four habits.
- Keep a list of what you use. A software bill of materials (SBOM) is a list of the parts inside your software, like the ingredient label on a food package. Our post on what an SBOM is and why it matters explains it further.
- Lock your versions. A lockfile records the exact versions you installed. The npm documentation says it exists so that teammates, deployments and continuous integration install exactly the same dependencies.
- Turn on two-factor authentication for every account that can publish or deploy.
- Watch for changes. A new version of something you use should not arrive silently.
None of these needs a budget. They need an afternoon and a habit.
How can Safeguard help?
Safeguard is a software supply chain security platform. Its SBOM and dependency scanning builds the list of what your software uses, including the blocks inside blocks. Reachability analysis helps you see which known problems your code can actually trigger. Policies and gates can stop a risky change at the pull request. Zero-day discovery and asset discovery help with the "do we use it?" question when news breaks. Autonomous remediation with fix pull requests is available but off by default, with every category set to Manual, so a person approves what happens.
You can try a free scan at gold.safeguard.sh/scan. If you prefer the terminal, the Safeguard CLI installs with a curl or PowerShell command.
Try it yourself
Open the demo and look at how a dependency inventory shows blocks you never chose directly. Click into one and notice how many layers deep it sits.
Click through it at your own pace, or open it full screen.
Quick check
Is a supply chain attack the same as a hack of my own website?
No. A hack of your own site goes straight at what you built. A supply chain attack goes through something you rely on, such as a package, an update or a build tool, so the bad code arrives looking like part of your normal work.
Do I have to be a big company to be a target?
No. Lookalike packages and stolen accounts do not depend on who you are. Attackers publish bait and wait for anyone to take it. Small teams often move fast and check less, which is why the basics matter.
Can scanning tools catch every type?
No tool catches every type. Scanners are good at known problems and at showing what you use. Brand new attacks, stolen accounts and tampered build steps need habits like pinning, review and monitoring on top.
Sources
- CISA advisory AA20-352A on the SolarWinds related compromise
- CISA alert on XZ Utils, CVE-2024-3094
- npm Docs: About two-factor authentication
- npm Docs: package-lock.json
- SLSA: About SLSA
- GitHub Docs: Security hardening for GitHub Actions
Last reviewed: 19 October 2026.
