What is Supply chain attack?

What it is

A supply chain attack goes after the things a piece of software depends on instead of attacking the software head-on. Modern programs are assembled from open-source libraries, build tools, update servers and contributors' work. If an attacker slips malicious code into any of those, every project that trusts it inherits the problem.

The mailroom is a fair analogy. Breaking into a locked office is hard. Swapping a package in the mailroom, so the office carries it inside itself, is easier.

Common forms

• Poisoned dependency. An attacker publishes a malicious package, or takes over a legitimate one, and developers install it as usual.
• Compromised update. The vendor's own build or update system is breached, so a signed, official update carries the malware. The 2020 SolarWinds incident is the best-known example.
• Malicious contribution. An attacker earns trust over time, or pressures a maintainer, and gets harmful code merged into a project. The 2024 xz Utils backdoor followed this pattern.
• Stolen credentials. An attacker steals a maintainer's account or publishing token and pushes a bad release.

Why it matters

The attack scales. One compromised library can reach thousands of companies at once, and the victims did nothing wrong except install what they always install. Many open-source projects are run by a few unpaid maintainers, which makes the human side, such as pressure, fake accounts and social engineering, a real weak point.

Supply chain attacks and AI

AI changes this in two ways. First, coding agents install packages, run build steps and open pull requests on their own, so an agent given broad access becomes a new route into the chain. An agent can also be fooled by prompt injection text hidden in a package or issue, and it may hold API keys worth stealing. Second, AI can make attacks cheaper to run, for example by generating plausible contributions or fake identities at scale. Defenders use AI too, to scan code and find remote code execution flaws earlier.

How to reduce the risk

• Pin dependency versions and review changes before upgrading.
• Keep credentials narrowly scoped and short-lived.
• Run agents and builds in an agent sandbox with an allowlist for network access.
• Require human review for code from new contributors.
• Keep a list of what your software contains, often called a software bill of materials.

Key points

• The attack targets what software trusts, not the software itself.
• One compromise can spread to many downstream users.
• Agents that install and contribute code widen the surface, so limit their access.