Software Supply Chain Security After Axios

If you run CI/CD pipelines and if you're reading this newsletter, you probably do. Last week's Axios compromise should have made you uncomfortable. It made me uncomfortable, and I've been building and securing pipelines for quite sometime.

Here's what happened and what I think we should all do about it.

The Three-Hour Window That Broke Trust

On March 31, 2026, attackers published two malicious versions of Axios, a package with roughly 100 million weekly npm downloads during a window of a little over three hours. Google Threat Intelligence Group attributed the campaign to UNC1069, a North Korea-nexus threat actor. During that window, any CI/CD pipeline or developer workstation that freshly resolved the affected versions and allowed lifecycle scripts to run could have been compromised. Projects with previously committed lockfiles were far less likely to be affected.

The initial compromise path was familiar. Credential theft on a maintainer's npm account, a malicious publish, and a post install script that downloaded a cross-platform RAT. But the downstream payload was serious: a staged dependency, macOS/Windows/Linux coverage, and cleanup behavior to hide the evidence. It worked against one of the most popular packages in the JavaScript ecosystem.

A Paper Had Already Called It

I happened to be reading an academic paper, "Research Directions in Software Supply Chain Security" by Williams et al., published in ACM TOSEM -the same week the Axios incident broke. The paper, written by fifteen researchers who had talked to 131 practitioners across 42 organizations and 15 government agencies, mapped out exactly three attack vectors: dependencies, build infrastructure, and humans.

The Axios compromise hit all three.

This is the part that keeps me up at night in my own DevOps work: we already know where the vulnerabilities are. The research is clear. The practitioners agree. And yet the defenses remain inadequate.

The Dependency Numbers Are Staggering

Sonatype logged 512,847 malicious packages in 2024, up 156% from the year before. Detection tools have false positive rates above 15%, which makes automated blocking impractical. Three thousand popular npm packages are abandoned. Vulnerabilities go undiscovered for an average of three years.

The Axios attacker didn't need to find a bug. They just needed to publish a new dependency called plain-crypto-js with a postinstall hook. NPM ran it automatically during install. No review. No warning.

Your Build Pipeline Is the Target

Any pipeline or workstation that freshly resolved Axios during the exposure window and allowed lifecycle scripts to run was a potential victim. Projects with committed lockfiles that didn't update were not affected. The trojan didn't need to trick a developer. It just needed the build system to do what build systems do.

Only 20% of software builds can be reproduced bit-for-bit. The rest can't prove they haven't been tampered with. SolarWinds demonstrated the category in 2020, but the Axios incident is a different mechanic — registry publish via a compromised maintainer account rather than build process infiltration. Same underlying failure: build systems trust what they install.

SLSA and Sigstore exist. Most organizations haven't adopted them. The tools are there. The adoption isn't.

The Human Problem Has No Patch

This one's personal for me. I work with open source tools every day, and I've seen the maintainer burnout firsthand.

The Axios attack started with a compromised maintainer account. The 2024 Tidelift survey found that 60% of open source maintainers are unpaid. They've tripled their security time commitment <from 4% to 11%> with zero additional compensation.

The xz-utils attack in 2024 was even worse: a multi-year social engineering campaign against a burned-out solo maintainer. The paper's authors admit no existing security practice could have prevented it.

You can mandate 2FA. You can enforce credential rotation. But the human attack surface is a funding and governance problem, not a technical one.

Six Things to Do This Week

I'm not going to pretend there's a silver bullet. The paper catalogs every major framework: SLSA, SBOMs, OpenSSF Scorecard, Sigstore and documents why each one alone is insufficient. Defense-in-depth is the only viable strategy.

Here's what I'm prioritizing in my own work, ordered by effort:

1. Pin exact dependency versions with integrity hashes. If your lockfile had pinned Axios 1.14.0 with a hash, the malicious 1.14.1 never would have installed.
2. Disable postinstall scripts in CI. Use  — ignore-scripts and whitelist explicitly. The axios RAT relied entirely on a postinstall hook.
3. Enable 2FA on every package registry account. npm, PyPI, RubyGems — all of them.
4. Run OpenSSF Scorecard on critical dependencies. Imperfect, but it surfaces red flags.
5. Adopt SLSA level 1 for your own builds. Generate provenance metadata. Costs almost nothing.
6. Fund your dependencies. If your business runs on open source maintained by unpaid volunteers, your security budget should include them.

Why This Matters for the Long Game

The Williams et al. paper isn't a prediction — it's a diagnosis. The researchers documented failure modes that 131 industry practitioners confirmed. The axios compromise demonstrated every one of those failure modes, at scale, against a trusted target, by a nation-state adversary.

The three-hour response window was impressive. But lockfiles, npm ci, and  — ignore-scripts would have blocked exposure without relying on detection at all. Response speed was the most visible defense that worked in real time — it shouldn't have been the primary one.

Read the paper. It won't make your dependencies safe. But it will show you exactly where the risks are.

https://dl.acm.org/doi/full/10.1145/3714464

If you found this useful, consider sharing it with your team. Supply chain security is one of those topics where awareness itself is a form of defense — the more people who know to pin versions and disable postinstall scripts, the smaller the blast radius of the next incident.

And there will be a next incident.

If you're not subscribed yet, join here www.tonsofskills.com for weekly deep dives on AI, DevOps, and the infrastructure decisions that matter.

Originally published at [startaitools.com]

(https://startaitools.com/posts/software-supply-chain-security/)*