In March 2024, a Microsoft engineer named Andres Freund noticed SSH logins on Debian unstable were taking 500 milliseconds longer than expected. That small anomaly led him to a backdoor buried inside XZ Utils, a compression library used in nearly every Linux distribution on Earth. The malicious code had been planted over two years by a contributor who patiently earned maintainer trust before slipping in an SSH authentication bypass. It was caught days before it would have shipped into major distros. Software supply chain attacks like this one do not exploit your code — they exploit the code you trust, the dependencies you never audit, and the build systems you assume are clean. From SolarWinds to XZ Utils to the polyfill.io hijack, attackers have learned that compromising one upstream component can compromise thousands of downstream victims at once. This post breaks down what these attacks actually look like, how often they're happening, and what security teams — including customers of platforms like Aqua Security — need to close the gap.
What Is a Software Supply Chain Attack?
A software supply chain attack is any compromise that inserts malicious code somewhere before it reaches production — in a dependency, a build pipeline, a CI/CD tool, or a software update mechanism — rather than attacking the running application directly. The classic example is SolarWinds in December 2020, where attackers compromised the build server for the Orion IT management platform and injected the SUNBURST backdoor into signed software updates, ultimately reaching roughly 18,000 organizations, including nine U.S. federal agencies. Unlike a traditional exploit against a live vulnerability, supply chain attacks poison the source: a malicious npm package, a hijacked GitHub Action, a tampered container base image, or a rogue maintainer commit. The 2021 Codecov breach followed the same playbook — attackers modified the Bash Uploader script for over two months, silently exfiltrating credentials and secrets from thousands of CI environments before anyone noticed.
How Often Are Software Supply Chain Attacks Happening in 2026?
They're happening at a scale that has grown roughly tenfold in five years. Sonatype's State of the Software Supply Chain research recorded over 245,000 malicious open source packages published in 2023 alone — more than the combined total from all prior years it had tracked since 2019. The npm and PyPI ecosystems remain the most targeted: campaigns like the 2021 ua-parser-js hijack (used in an estimated 7 million weekly downloads) and the ongoing wave of typosquatted packages mimicking popular libraries show no sign of slowing. In June 2024, the polyfill.io domain — embedded via <script> tags on more than 100,000 websites — was acquired by a new owner and began injecting malware directly into visitor browsers, forcing Cloudflare and Fastly to stand up clean replacement CDNs overnight. Attackers have realized that a single poisoned dependency scales better than a thousand individual phishing emails.
What Do Real Software Supply Chain Attacks Actually Look Like?
They fall into a handful of repeatable patterns: build-system compromise, dependency confusion, maintainer takeover, and update-channel hijacking. The 3CX incident in March 2023 is a rare documented case of a "double supply chain attack" — 3CX's desktop softphone app was compromised because one of its own employees had installed a trojanized trading application (X_Trader) from a separate, earlier supply chain attack, giving attackers a foothold to sign and distribute malicious 3CX installers to an estimated 600,000 customers. The XZ Utils incident showed maintainer takeover in slow motion: a persona named "Jia Tan" spent roughly two years contributing legitimate patches before introducing obfuscated backdoor code in versions 5.6.0 and 5.6.1. And the 2018 event-stream compromise — where a malicious actor volunteered to maintain an abandoned but widely-used npm package, then added a Bitcoin-wallet-stealing payload targeting a single downstream app — remains the textbook case for why unmaintained dependencies are a live risk, not a dormant one.
Why Do Traditional Security Tools Miss These Attacks?
They miss them because most tooling was built to scan artifacts, not verify provenance. Container and runtime security platforms — Aqua Security's Trivy and its broader Cloud Native Application Protection Platform among them — are genuinely strong at finding known CVEs in images, misconfigurations in Kubernetes, and anomalous runtime behavior once a workload is already deployed. That's essential coverage. But a backdoor like the one in XZ Utils 5.6.1 was not a known CVE at build time — it was novel, deliberately obfuscated, and shipped inside a "trusted" upstream release. Vulnerability scanners match against databases of already-disclosed issues; they generally cannot tell you whether a package was built by the maintainer of record, whether a CI job was tampered with, or whether an SBOM claim matches what actually ran. That gap — between "no known CVEs" and "this artifact is actually what it claims to be" — is where the majority of high-impact supply chain incidents since 2020 have originated.
What Does the Industry's Own Research Say About the Threat?
Even the vendors focused on runtime and container security agree the trendline is accelerating. Aqua Security's own Nautilus research team has published multiple reports tracking a sharp rise in software supply chain attacks targeting open source registries, container images on public registries, and CI/CD misconfigurations, and it's part of why the industry broadly points to Gartner's earlier forecast that 45% of organizations worldwide will have experienced an attack on their software supply chains by 2025, up from single digits a few years prior. The consensus across Aqua's research, Sonatype's package-ecosystem data, and Google's SLSA framework is the same: attackers have shifted left of the vulnerability scanner, into the build pipeline and the dependency graph itself. Where platforms differ is in what they're built to verify once you accept that premise — runtime and image scanning answer "is this workload safe to run," while provenance and build-integrity verification answer "is this artifact actually what it claims to be, built by whom it claims, from the source it claims."
How Safeguard Helps
Safeguard is built specifically for that second question. Rather than treating the software supply chain as a scanning problem bolted onto container security, Safeguard treats it as a provenance and trust problem from source to production:
- SBOM generation and continuous verification — Safeguard generates and continuously reconciles software bills of materials against what's actually deployed, so a dependency swap or a tampered build output shows up as a diff, not a surprise six months later.
- Build and CI/CD attestation — Safeguard verifies that artifacts were built by the pipeline and commit history you expect, aligned with frameworks like SLSA and in-toto, closing the exact gap that let the SolarWinds and Codecov build-server compromises go undetected for months.
- Dependency and registry risk scoring — new or updated packages, maintainer changes, and anomalous publish behavior (the same signals that would have flagged the XZ Utils and event-stream takeovers) are surfaced before they reach a build, not after.
- Third-party and open source posture management — Safeguard maps transitive dependencies and flags abandoned or single-maintainer packages carrying outsized blast radius across your environment.
- Works alongside existing runtime tooling — teams already running Aqua Security, Trivy, or another CNAPP for image scanning and runtime protection can layer Safeguard in front of the pipeline to cover the provenance and build-integrity gap those tools weren't designed to close, rather than ripping and replacing what already works.
Software supply chain attacks succeed because they exploit trust that was never actually verified — trust in a maintainer, a build server, a CDN, or a signed update. Runtime scanning tells you what's running today is free of known issues. Safeguard tells you that what's running today is actually what your team built, from the source it claims, by the process you approved. In a threat landscape where the next XZ Utils could already be sitting in your dependency tree, that distinction is the difference between catching an attack in code review and explaining a breach in a postmortem.