In March 2024, a Microsoft engineer named Andres Freund noticed his SSH logins were taking 500 milliseconds longer than usual. That small anomaly led him to discover a backdoor planted inside XZ Utils, a compression library embedded in nearly every Linux distribution on Earth. The attacker had spent over two years building trust in the project before slipping malicious code into a release. It is one of the most sophisticated software supply chain attacks ever found — and it was caught by accident, days before it would have shipped broadly into production systems.
That near-miss is a useful lens for this post. Software supply chain threat vectors have moved far beyond "patch your dependencies." Attackers now target the humans who maintain packages, the CI/CD pipelines that build software, and the trust relationships between vendors and customers. Below, we break down the actual mechanics of these attacks, using real incidents and numbers, and compare how vendors like Chainguard approach the problem versus how Safeguard closes the remaining gaps.
What Counts as a Software Supply Chain Threat Vector Today?
A software supply chain threat vector is any point where an attacker can insert malicious code or behavior before it reaches a production environment, rather than attacking that environment directly. Gartner has estimated that 45% of organizations worldwide will have experienced a software supply chain attack by 2025, up threefold from 2021. The category spans at least five distinct attack surfaces: source code repositories, open-source dependencies, build and CI/CD systems, package registries, and third-party vendor software. Sonatype's 2024 State of the Software Supply Chain report logged over 512,000 malicious packages discovered across open-source ecosystems that year alone — more than the combined total from the previous four years. The shift is structural: attackers have realized that compromising one popular package or one CI runner gives them leverage over thousands of downstream victims at once, which is a far better return on effort than attacking hardened production infrastructure directly.
Why Did the XZ Utils Backdoor Nearly Succeed?
The XZ Utils backdoor (CVE-2024-3094) nearly succeeded because it exploited maintainer burnout and social trust rather than a technical flaw. A pseudonymous contributor known as "Jia Tan" spent roughly two years, starting in 2021, submitting legitimate patches to the XZ Utils project, gradually earning co-maintainer status from the overworked original maintainer. In February 2024, that access was used to insert obfuscated malicious code into the build scripts — not the visible source code — that created a backdoor in liblzma, allowing remote unauthenticated SSH access on affected systems. Because XZ Utils is a dependency of systemd on major Linux distributions, this backdoor was days away from landing in Debian and Fedora stable releases before Freund's discovery. This incident showed that identity and reputation, not just code, are now attack surfaces — a distinction that most traditional dependency scanners are not built to detect.
How Do Compromised CI/CD Pipelines Turn One Breach Into Thousands?
Compromised CI/CD pipelines turn one breach into thousands because a single poisoned build step runs automatically across every repository that references it, with no additional attacker effort. The clearest recent example is the March 2025 compromise of tj-actions/changed-files, a GitHub Action used in an estimated 23,000 repositories. Attackers gained access to the action's repository and modified its code to dump CI runner memory — potentially exposing secrets like AWS keys, GitHub tokens, and npm credentials — into public build logs, retroactively tagging the malicious commit across multiple historical version tags (CVE-2025-30066). Within hours, GitHub removed the action entirely rather than trying to selectively patch it. This follows the same pattern as the 2021 Codecov bash uploader compromise, where a modified script silently exfiltrated CI environment variables from an unknown number of customers for over two months before detection. Pipelines are attractive precisely because they have broad credentials and run unattended, and most organizations still trust third-party Actions and scripts by default.
What Made the SolarWinds and 3CX Attacks Different From Typical Malware?
The SolarWinds and 3CX attacks were different from typical malware because the malicious code shipped inside a digitally signed, officially distributed update — meaning victims installed it voluntarily through their normal patch process. In the SolarWinds case, disclosed in December 2020, attackers compromised the build system for the Orion platform and inserted the SUNBURST backdoor into signed software updates pushed to roughly 18,000 customers, including nine U.S. federal agencies. The 3CX incident in March 2023 was notable for being a "supply chain attack caused by a supply chain attack": 3CX's desktop app was compromised after an employee installed a trojanized version of a trading application called X_Trader, which gave attackers a foothold to poison 3CX's own build pipeline. Both cases defeated code-signing and vendor trust — the exact mechanisms organizations rely on to decide what to install. This is why static trust in a signature or a vendor name is no longer sufficient; behavior at build time and runtime has to be verified continuously.
Why Isn't Generating an SBOM Enough to Stop These Attacks?
Generating an SBOM isn't enough to stop these attacks because an SBOM is a point-in-time inventory, not a detection system — it tells you what is in your software, not whether it's behaving maliciously right now. The U.S. Executive Order 14028 made SBOMs a de facto requirement for federal software vendors starting in 2021, and adoption has grown sharply since, yet incidents have not slowed: Sonatype recorded a 156% year-over-year increase in malicious open-source packages in 2024 despite widespread SBOM tooling. This is because most attacks — like the polyfill.io compromise in June 2024, where a Chinese company acquired the popular polyfill.io CDN domain and began injecting malware into over 100,000 sites that had legitimately embedded the script for years — happen after the SBOM was generated and everything looked clean. This is the gap where hardened-image vendors like Chainguard have focused their energy, minimizing the attack surface of base container images and enforcing keyless signing through Sigstore. That's valuable for reducing what ships in a given image, but it doesn't address a dependency that turns malicious post-deployment, a compromised CI runner, or a maintainer account takeover happening in a package you already trusted.
Which Industries Are Most Exposed, and Is the Problem Getting Worse?
Financial services, healthcare, and critical infrastructure are the most exposed industries, and the problem is measurably getting worse, not better. IBM's 2024 Cost of a Data Breach report put the average cost of a supply chain-linked breach at $4.76 million, above the global average breach cost of $4.88 million and taking on average 11% longer to identify and contain than other breach types. The 2024 Change Healthcare ransomware incident, triggered through a compromised third-party credential, disrupted claims processing for an estimated one-third of U.S. patient records and is estimated to have cost UnitedHealth Group over $2.9 billion. Meanwhile, the npm ecosystem alone saw attackers publish an average of more than 1,300 malicious packages per month in 2024 according to multiple threat intelligence vendors, using typosquatting, dependency confusion, and star-jacking to trick developers into pulling compromised code. Regulatory pressure is catching up — the EU's Cyber Resilience Act and updated SEC disclosure rules both now impose real deadlines and liability on organizations that fail to detect these incidents quickly — but detection capability across most engineering organizations still lags well behind the sophistication of the attacks being launched against them.
How Safeguard Helps
Safeguard is built around the gap the examples above have in common: attacks that occur or activate after code has already passed a scan, been signed, or shipped in a "hardened" image. Rather than treating supply chain security as a one-time inventory exercise, Safeguard continuously monitors dependencies, build pipelines, and runtime behavior for the signals that preceded XZ Utils, tj-actions, and polyfill.io — anomalous maintainer activity, unexpected changes to previously trusted packages, and CI jobs behaving outside their normal footprint.
Concretely, Safeguard combines automated SBOM generation with continuous behavioral monitoring of open-source dependencies, so a package that looked clean at scan time but starts exfiltrating data or phoning home post-release gets flagged immediately, not at the next audit cycle. It extends visibility into CI/CD pipelines themselves, watching for the kind of unauthorized workflow modifications and secret exposure seen in the Codecov and tj-actions incidents, and enforcing least-privilege access for build credentials. And where vendors like Chainguard reduce risk by minimizing and signing what goes into a container image, Safeguard adds the layer above and below that: verifying the provenance and behavior of everything that touches the build and deployment path, including third-party vendor software and internally maintained services that never touch a Chainguard-hardened image at all.
For security and platform teams, that means fewer blind spots between "the SBOM said this was safe" and "this dependency is now doing something it shouldn't." Given that the average time to identify a supply chain breach is measured in months, not hours, closing that detection gap is the difference between catching the next XZ Utils before it ships and finding out about it the way Debian almost did — by accident, and just in time.