"Supply chain" is one of those phrases that means everything and nothing. In software security it has a precise meaning: the set of dependencies, build infrastructure, and distribution channels by which code reaches a running system. The threat is real, the incidents are public, and the defensive playbook is starting to settle into a coherent shape. The arc from SolarWinds in 2020 to XZ Utils in 2024 traces an industry learning, slowly, what the problem actually is.
SolarWinds and the build-system class of attack
The SolarWinds Orion compromise, disclosed in December 2020 by FireEye, became the canonical software supply-chain incident because of the specific mechanism. The attackers, Russian SVR, tracked as APT29 / NOBELIUM, compromised SolarWinds’ build environment and inserted SUNBURST malware into Orion software updates that were then signed by SolarWinds’ legitimate code-signing certificate and distributed to roughly 18,000 customers. The malware was active in customer networks for months before discovery.
What SolarWinds taught the industry, beyond the obvious geopolitical lessons:
Build-system compromise is high-leverage. One intrusion into a vendor’s build pipeline reaches every customer who applies the next update.
Code signing as an integrity control is broken when the signing infrastructure is itself compromised. The customers received signed binaries; the signatures verified; the software was malicious.
Detection cost is asymmetric. Customers had no realistic way to detect SUNBURST without specific IOCs. The discovery came when FireEye, a SolarWinds customer, found anomalous behaviour in their own environment.
The CISA SolarWinds advisories at cisa.gov/news-events/cybersecurity-advisories and the joint NSA / FBI / CISA report remain the authoritative public account.
Codecov, 3CX, and the watering-hole flavour
Codecov in April 2021 was a smaller but equally instructive case. The attacker compromised Codecov’s Bash uploader script, used in CI/CD pipelines across thousands of organisations, and exfiltrated environment variables (API keys, credentials, tokens) from those pipelines. The script was hosted on Codecov’s infrastructure and pulled by curl | bash invocations everywhere.
3CX in March 2023 followed a similar pattern: the legitimate 3CX desktop softphone application was modified upstream to include a multi-stage backdoor (TAXHAUL / SmoothOperator), then signed and distributed to customers. The attribution to a North Korean Lazarus subset and the cascading chain (3CX itself was compromised via a different supply-chain incident at trading-software vendor Trading Technologies) made it the first publicly documented "supply chain compromise of a supply chain compromise."
The pattern across these incidents: trust in the vendor was the vulnerability. Customers had done nothing wrong. The defensive response had to live somewhere other than "trust the vendor more carefully."
The npm and PyPI dependency ecosystems
A different class of attack lives in the open-source registries. The threat models are slightly different but the consequences are similar:
Typosquatting. Malicious packages with names close to legitimate ones (lodahs instead of lodash, colors-js instead of colors). Sonatype tracks thousands per year.
Account takeover of legitimate maintainers. The 2018 event-stream incident is the canonical case: a maintainer transferred control to a stranger who quietly added cryptocurrency-stealing code that targeted Copay wallets.
Dependency confusion. Alex Birsan’s 2021 work demonstrated that internal package names referenced in build configuration could be hijacked by registering them on public registries; the build system would prefer the public version. He triggered code execution at PayPal, Apple, Microsoft, and dozens of others.
Protestware. Maintainers introducing destructive or politically motivated payloads into their own packages. The node-ipc incident of 2022 wiped files on machines with Russian or Belarusian IP addresses; the maintainer was making a political statement; thousands of unrelated organisations were caught in the blast radius.
Malicious AI-generated packages. A growing problem in 2025–2026: LLMs hallucinating package names that attackers then register and populate with malicious code. Developers who copy-paste the AI suggestion install the malicious package.
The OpenSSF maintains a "Malicious Packages" repository at github.com/ossf/malicious-packages tracking these incidents.
XZ Utils and the patient-attacker thesis
The XZ Utils backdoor, disclosed in late March 2024, was the most sophisticated software supply-chain attack ever made public. The malicious actor, operating under the persona "Jia Tan," spent over two years contributing to the XZ Utils project, a widely used compression library bundled in nearly every Linux distribution, until they were trusted as a maintainer. They then introduced a backdoor in versions 5.6.0 and 5.6.1 that triggered through a complex chain involving the OpenSSH SSH daemon’s link to liblzma.
Discovery was accidental. A Microsoft engineer, Andres Freund, noticed a 500ms latency in SSH logins on a Debian testing system, investigated, and unravelled the entire chain. Several dimensions made XZ Utils unique:
The attacker invested years of social engineering into becoming a maintainer. Open-source trust models have not handled this well.
The backdoor was hidden in test fixture files, decoded at build time by build scripts. Standard source code review would not have caught it.
The trigger was specific to OpenSSH dynamically linking liblzma via systemd. Most Linux distributions, but not all, were affected.
The disclosure happened during a release-candidate window, before stable distributions had shipped 5.6.x. The fix was therefore mostly preventative, a near-miss rather than a mass exploitation.
The XZ Utils incident triggered a wave of soul-searching in the open-source community about funding, maintainer burnout, and trust delegation. Filippo Valsorda’s "Maintainer-Month" essays and the OpenSSF’s "Securing Open Source Foundations" report remain useful reading.
Defensive practice: SBOM, SLSA, and beyond
The defensive playbook has crystallised around four practices:
Software Bill of Materials. An SBOM lists every component in a piece of software, including transitive dependencies. The CycloneDX and SPDX standards are the dominant formats. Executive Order 14028 in the United States made SBOMs a requirement for federal procurement, accelerating adoption. The SBOM does not solve supply-chain attacks; it makes them measurable. When XZ Utils 5.6.0 was disclosed, organisations with SBOMs could answer "are we exposed" in minutes rather than days.
SLSA (Supply-chain Levels for Software Artifacts). Google’s SLSA framework, at slsa.dev, defines maturity levels for build provenance: signed builds, verifiable build environments, hermetic builds with immutable inputs, two-person review for releases. SLSA Level 3+ would have raised the bar against several recent supply-chain incidents.
Dependency review at the developer workflow. GitHub Dependabot, Snyk, Sonatype, JFrog, and others scan dependency graphs against known vulnerability and malicious-package databases. Useful but limited: signature-based detection misses zero-day backdoors.
Sigstore and reproducible builds. Sigstore (also at sigstore.dev) provides keyless signing tied to OIDC identities; reproducible builds let independent verifiers confirm that the released binary matches the released source. Both are still gaining adoption but represent the architectural fix.
The broader lesson, restated: software supply chain security is not a tool. It is a set of organisational practices that say, repeatedly, "we will not trust unverified code." The supply chains we have built optimise for speed of integration, not for verifiability. The shift in the other direction is happening, slowly, and the next SolarWinds-class incident is already in progress somewhere. The question is whether enough of the playbook has been deployed to catch it.