Supply chain attack
Hacking a trusted supplier so its normal updates carry the attack to everyone else.
Modern software is assembled from parts made by others: open source libraries pulled in by a package manager, build tools, cloud services, update servers. A supply chain attack does not go after the final target directly. It compromises one of those trusted parts, and lets the normal flow of updates deliver the malicious code to every company and person downstream.
Two cases show the pattern. In an attack discovered in 2020, intruders had slipped a backdoor into updates of SolarWinds Orion, a network monitoring product that thousands of organizations, including US government agencies, installed as routine. In 2024 a developer noticed that xz, a compression library present in many Linux systems, had been given a hidden backdoor by a contributor who spent around two years earning the maintainers' trust. Simpler versions are common too: publishing a malicious package with a name one letter off from a popular one, or stealing a maintainer's password and pushing a poisoned release.
It is hard to defend against because the code arrives signed, from the expected source, through the channel you are supposed to trust. The responses focus on knowing and verifying what you depend on: pinning exact versions, keeping an inventory of components (an SBOM), checking signatures and provenance with frameworks like SLSA, protecting maintainer accounts with strong 2FA, and limiting what each component is allowed to do.
Keep in mind
- The attacker compromises a supplier, and normal updates spread the attack.
- SolarWinds (2020) and the
xzbackdoor (2024) are the textbook examples. - Open source dependencies and build systems are frequent targets.
- Defenses: pinned versions, SBOMs, signed builds and protected maintainer accounts.
Go deeper
- Supply chain attack on Wikipedia
- SLSA: a framework for software supply chain integrity
- The XZ Utils backdoor on Wikipedia
