xz-utils, Log4j, event-stream — the pattern is clear. 60% of maintainers work unpaid. Supply chain attacks doubled in 2025. Here's what's actually broken.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
On March 28, 2024, a Microsoft engineer named Andres Freund was benchmarking PostgreSQL on Debian Sid. SSH logins were taking 500 milliseconds instead of the usual 100. That's it. A 400-millisecond anomaly noticed by one person doing unrelated work.
That person — and only that person — stood between a CVSS 10.0 backdoor and hundreds of millions of Linux servers running OpenSSH. The backdoor in xz-utils had been planted over 2.6 years by someone using the name "Jia Tan," who social-engineered their way into maintainership of a compression library that ships with virtually every Linux distribution on Earth.
We got lucky. Absurdly, unreasonably lucky. And the terrifying part? The same attack pattern has worked before, is working right now, and will work again — because the structural problems that enabled it haven't changed.
Software supply chain attacks aren't a theoretical risk. They're an accelerating crisis with hard dollar figures attached.
Cybersecurity Ventures projects the global annual cost of software supply chain attacks will hit $60 billion in 2025 and reach $138 billion by 2031 — a 15% year-over-year growth rate. Supply chain attacks more than doubled globally during 2025.
Here's a snapshot of the escalation:
| Metric | Value | Source |
|---|---|---|
| Global cost (2025) | $60 billion | Cybersecurity Ventures |
| Projected cost (2031) | $138 billion | Cybersecurity Ventures |
| Monthly attacks (Oct 2025) | 41 (record high) | Cyble |
| Monthly average (Apr-Oct 2025) | 28+ per month | Cyble |
| Monthly average (2024-Mar 2025) | 13 per month | Cyble |
| Malicious npm packages (2025) | 454,648 | Socket.dev |
| Open source malware growth (2025) | +73% YoY | ReversingLabs |
| Orgs hit by supply chain incident | 70%+ | Industry surveys |
Over 70% of organizations reported experiencing at least one third-party or software supply chain-related security incident. Attackers published 454,648 malicious npm packages in 2025 alone. Over 99% of all open source malware now targets npm.
This isn't a trend line. It's a hockey stick.
The xz-utils backdoor (CVE-2024-3094) wasn't a smash-and-grab. It was a 2.6-year social engineering campaign that exploited the single weakest point in open source: a burned-out maintainer.
Here's the timeline, reconstructed from Russ Cox's detailed analysis and Kaspersky's investigation:
October 2021: An account using the name "Jia Tan" submits an innocuous patch to xz-utils. Just a helpful contributor.
May-June 2022: Sockpuppet accounts — Jigar Kumar, krygorin4545, Dennis Ens — appear on the xz-devel mailing list. They don't contribute code. They pressure Lasse Collin, the sole maintainer, complaining about slow releases and unresponsive maintenance. Collin, who has publicly discussed his mental health challenges, eventually yields.
December 2022: Jia Tan becomes a co-maintainer with release privileges. They create the GitHub organization for xz-utils and set their own email as the default contact.
June 2023: Jia Tan introduces IFUNC resolvers through seemingly legitimate commits. These will later be weaponized to hijack OpenSSH's RSA_public_decrypt function at runtime.
February 24, 2024: xz-utils 5.6.0 ships with the backdoor embedded in the release tarballs — but not in the git source. The malicious code only exists in the distribution archives, making it invisible to anyone reading the repository.
March 9, 2024: xz-utils 5.6.1 ships with refinements to the backdoor.
March 28, 2024: Andres Freund notices the 500ms SSH delay, investigates, finds Valgrind errors pointing to liblzma, and reports CVE-2024-3094.
The entire internet's SSH infrastructure was saved because one engineer was annoyed by a half-second of latency during a benchmark. Let that sink in.
The xz-utils attack was sophisticated. But the underlying vulnerability — a single overworked maintainer handing over keys to a stranger — is the norm, not the exception.
In 2018, Dominic Tarr handed over maintenance of the event-stream npm package (2 million weekly downloads) to a stranger named right9ctrl. Tarr's explanation was brutally honest: "I don't get anything from maintaining this module" and hadn't used it "for years."
Right9ctrl added a dependency called flatmap-stream containing targeted malware designed to steal Bitcoin from the Copay wallet application. The malicious code sat undetected for over two months before a computer science student named Ayrton Sparling caught it.
Same pattern: burned-out maintainer, social engineering, months of undetected compromise.
Log4j, a Java logging library maintained by a handful of volunteers, contained CVE-2021-44228 — a CVSS 10.0 remote code execution vulnerability. NIST gave it the maximum severity score. Check Point called it "a true cyber-pandemic."
The average incident response cost exceeded $90,000 per organization. One in four organizations in Arctic Wolf's customer base was targeted with exploitation attempts. Three ransomware groups — LockBit (26.9%), Conti (19.2%), and Alphv/BlackCat (11.5%) — accounted for roughly 60% of all Log4Shell incident response cases.
The DHS Cyber Safety Review Board determined that fully remediating Log4Shell would take a decade. As of 2024, 38% of applications still use vulnerable versions of Log4j, with 2.8% still running the exact Log4Shell-affected versions.
A decade. For a logging library.
The Russian Foreign Intelligence Service compromised SolarWinds' build system, injecting malware into software updates sent to nearly 18,000 customers. Victims included the Pentagon, Department of Homeland Security, State Department, Department of Energy, the National Nuclear Security Administration, and companies like Microsoft, Cisco, Intel, and Deloitte.
SolarWinds was different in that the target was a commercial vendor, not an open source project. But the lesson is identical: software supply chains are single points of failure, and we trust them far too implicitly.
Attackers modified Codecov's Bash Uploader script in January 2021 and exfiltrated environment variables — API keys, tokens, credentials — from customers' CI/CD pipelines for over two months before discovery. Hundreds of networks were reportedly compromised.
The ua-parser-js npm package, with 7 million weekly downloads, was hijacked to deliver password-stealing malware and crypto miners. The malicious versions harvested Chrome cookies, saved passwords, and additional data from every infected system.
Every one of these incidents traces back to the same structural failure: critical infrastructure maintained by volunteers who are overworked, underpaid, and burning out.
The numbers tell the story:
This isn't just about individual packages. In 2025, Kubernetes announced the retirement of Ingress NGINX due to maintainer burnout — one of the most widely used components in the entire ecosystem, receiving no security patches after March 2026. External Secrets Operator, used in critical enterprise systems globally, froze all updates with four of five maintainers burned out.
GitHub added 36 million developers in 2025, but the platform's own analysis shows this growth is creating sustainability problems. Maintainers describe the review burden as "a denial of service attack on human attention."
The asymmetry is staggering. Fortune 500 companies build billion-dollar products on libraries maintained by someone who gets zero compensation and handles GitHub issues between their actual job and dinner. When that person burns out — and they will — the attack surface opens up.
The pressure cooker doesn't just produce vulnerabilities. Sometimes maintainers snap.
In January 2022, Marak Squires, the maintainer of colors.js (3.3 billion lifetime downloads, 19,000+ dependents) and faker.js, deliberately sabotaged both libraries. He pushed an update that added an infinite loop, causing a denial-of-service for every Node.js application depending on the package.
His stated reason: mega-corporations extract enormous value from open source and give nothing back.
Two months later, the maintainer of node-ipc embedded "protestware" that detected whether the developer was geolocated in Russia or Belarus. If so, it replaced all file contents with a heart emoji. An act of political protest distributed through a software supply chain used by thousands of applications.
These aren't supply chain attacks in the traditional sense. They're symptoms of a system so broken that the people maintaining it are actively rebelling against it. And from a security perspective, the impact is indistinguishable from a malicious attack.
While social engineering gets the headlines, the brute-force approach is growing faster.
In 2025, attackers published 454,648 malicious npm packages. The IndonesianFoods campaign alone generated over 100,000 malicious packages in just a few days by creating a new package every seven seconds.
Typosquatting remains devastatingly effective. Registering metamaks instead of metamask, or browser-cookies3 instead of browser-cookie3 — trivial name confusion that catches real developers in real projects. Check Point identified over 500 malicious typosquatting packages on PyPI alone. In February 2026, more than 1,000 packages using the "claw" naming pattern surfaced on npm and PyPI.
The Shai-Hulud 2.0 campaign shifted from post-install to pre-install execution, creating over 25,000 malicious repositories across roughly 350 GitHub users. Pre-install hooks mean the malicious code runs before you even finish typing npm install.
PyPI now automatically flags potential typosquatting during package creation. That's a start. But npm — the most targeted ecosystem — still lacks equivalent protections at scale.
The industry response to supply chain attacks has been real but insufficient. Here are the major initiatives and their honest assessments:
CISA released updated SBOM minimum elements in August 2025, expanding requirements to include component hashes, license info, and generation context. The EU Cyber Resilience Act mandates SBOMs by December 2027 for all products with digital elements sold in Europe.
The reality: SBOMs tell you what's in your software. They don't stop compromised code from getting there. Knowing you depend on xz-utils 5.6.1 is useless if nobody has flagged it yet. SBOMs are an inventory, not a defense.
SLSA (Supply chain Levels for Software Artifacts) and Sigstore provide build provenance and artifact signing. With GitHub's built-in attestation support, you can now reach SLSA Level 2 for most artifact types in an afternoon.
The reality: SLSA would have caught the xz-utils attack — the backdoor was only in release tarballs, not in the git source, and build provenance would have flagged the discrepancy. But adoption remains challenging. A study of 1,523 GitHub issues across 233 repositories found practitioners face significant barriers including "complex implementation" and "unclear communication" of requirements.
The OpenSSF Scorecard auto-generates security scores for open source projects by checking for things like branch protection, dependency pinning, code review practices, and CI/CD security.
The reality: Scorecard flags process gaps but can't detect a sophisticated attacker who follows all the rules. Jia Tan's commits were well-formatted, well-reviewed, and gradually built trust. A good Scorecard rating doesn't mean a project is safe.
The US Executive Order 14028 requires federal software suppliers to provide verifiable provenance. The EU Cyber Resilience Act enters full enforcement in December 2027, with vulnerability reporting requirements starting September 2026.
The reality: Regulation forces baseline compliance but moves at government speed. The CRA explicitly carves out non-commercial open source projects, meaning the most vulnerable projects — the unfunded ones — aren't covered.
Waiting for the industry to fix itself isn't a strategy. Here's what you can implement today, ordered by impact and effort:
1. Pin your dependencies. Stop using ^ and ~ in package.json. Use exact versions. Lock files help but aren't enough — lock files can be regenerated during CI/CD.
{
"dependencies": {
"express": "4.21.2",
"lodash": "4.17.21"
}
}
2. Enable lockfile-only installs in CI.
# npm
npm ci
# pnpm
pnpm install --frozen-lockfile
# yarn
yarn install --immutable
3. Run OpenSSF Scorecard on your critical dependencies.
# Install scorecard
brew install scorecard
# Check a dependency
scorecard --repo=github.com/expressjs/express
4. Audit your dependency tree regularly.
npm audit
# Or better:
npx socket-security/cli report
5. Implement SLSA Level 2 for your builds. GitHub Actions makes this straightforward:
# .github/workflows/build.yml
jobs:
build:
permissions:
id-token: write
contents: read
attestations: write
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build
- uses: actions/attest-build-provenance@v2
with:
subject-path: 'dist/**'
6. Generate and store SBOMs. Not because they're a silver bullet — because when the next Log4Shell drops, you need to know in minutes whether you're affected, not days.
# Using syft
syft packages dir:. -o spdx-json > sbom.json
# Using cdxgen
npx @cyclonedx/cdxgen -o sbom.json
7. Set up dependency review for PRs. GitHub's dependency review action flags known vulnerabilities before merge:
- uses: actions/dependency-review-action@v4
with:
fail-on-severity: moderate
8. Fund your critical open source dependencies. I know, I know — "we don't have budget for that." But consider: the average Log4Shell incident cost $90,000. GitHub's Secure Open Source Fund gives maintainers $10,000 each. You can also contribute through Open Source Pledge or direct sponsorship.
9. Establish a vendor security assessment for open source. Treat critical dependencies like you'd treat a SaaS vendor. Check: How many active maintainers? Is there bus factor of more than one? Are releases signed? Is the build reproducible?
10. Implement runtime monitoring. Tools like Falco, Sysdig, or even basic eBPF-based monitoring can catch unexpected network connections or file access from your dependencies at runtime — which is exactly how the xz-utils backdoor would have manifested.
I've been watching supply chain security discourse for years, and here's my honest take: we're investing in the wrong layer.
SBOMs, SLSA, Sigstore, OpenSSF Scorecard — they're all important. They're all necessary. And they're all treating symptoms instead of the disease.
The disease is that we built a $6 trillion global technology industry on top of code maintained by volunteers who we don't pay, don't support, and don't even thank. We then act shocked when one of them burns out and hands the keys to a stranger, or when a state-sponsored actor spends three years infiltrating a project because they know nobody's watching.
The xz-utils attack cost approximately $0 to execute. The attacker needed a laptop, a VPN, and patience. The defense industry that's grown up around supply chain security is projected to be worth billions. But the actual fix — paying Lasse Collin a full-time salary to maintain xz-utils, hiring a second maintainer, funding security audits — would have cost maybe $300,000 per year. For a piece of software that runs on every Linux server on the planet.
Here's what I think will actually happen: regulations will force enterprises to generate SBOMs and check compliance boxes. Security vendors will sell expensive tools. And the next xz-utils-style attack will succeed, because nobody fixed the human problem at the center of it.
The Jia Tan attack wasn't a technology failure. It was a social engineering attack against a single person who was drowning and asked for help, and the attacker was the only one who showed up. Until we fix that — the funding model, the maintainer support, the recognition that open source infrastructure is actual infrastructure — the tools are just better locks on a house with no walls.
I'm not saying don't adopt SLSA or SBOMs. Adopt them. They help. But if your "supply chain security strategy" is entirely tooling and zero funding for the humans maintaining your dependencies, you're doing security theater.
The next xz-utils is already in progress. Someone, somewhere, is patiently building trust in a project you depend on. The only question is whether they'll be caught by luck again — or whether we'll have actually built something better by then.
I wouldn't bet on it.