A Light Look at Supply Chain Security

Intro

Every day, we install, build, and deploy software. Commands like npm install, pip install, go get, and cargo add are so familiar that they rarely feel like security boundaries. Finding a package, installing it, and using it has become almost automatic.

Then, in late March 2026, a troubling piece of news appeared: malicious versions of axios, one of the most widely used HTTP clients in the JavaScript ecosystem, had been published to npm.

Microsoft Threat Intelligence reported that, on March 31, 2026, axios@1.14.1 and axios@0.30.4 were identified as malicious versions containing a malicious dependency. According to its analysis, that dependency contacted C2 infrastructure and downloaded OS-specific second-stage RAT payloads. GitLab Advisory also described both versions as having been published through a compromised maintainer account, with plain-crypto-js@4.2.1 used to distribute a cross-platform RAT.

What made this incident uncomfortable was that it was not the familiar story of an ordinary vulnerability somewhere in the axios codebase. Datadog Security Labs noted that the key change in malicious axios@1.14.1 was not in axios source logic itself, but in the plain-crypto-js dependency added to package.json. Trust broke down between a familiar package name, a patch release that looked normal, and an installation command developers run every day.

So the real question was not simply, “Which axios version should we downgrade to?” The more important question was this:

Is the software we install, build, and deploy every day really the software we think it is?

What We Trust

The package name is correct.
The registry will return the right files.
A lockfile means the dependency tree will be reproducible.
The artifact produced by GitHub Actions matches the source code.
A release tag means the release went through the expected process, and a signed update means it is safe.

These assumptions look obvious on the surface, but supply chain attacks exploit the space between them.

Attackers do not always need to find a vulnerability in the final application. They can instead compromise something the final application trusts. Dependency packages, maintainer accounts, build pipelines, package registries, update channels, installation scripts, and deployment artifacts can all become attack surfaces.

NIST SP 800-161 Rev. 1 treats supply chain risk as the risk that products or services acquired by an organization may contain malicious functionality, be counterfeit, or become vulnerable because of weaknesses in development or manufacturing practices. NIST SP 800-204D also frames the software supply chain as more than a list of libraries. It includes the CI/CD activities through which source code is built, tested, packaged, and deployed into a new software version.

In other words, the core question in a supply chain attack is not only “Where was the malicious code hidden?” The deeper question is: “How was the malicious code accepted as normal?”

Attack Surface

Software supply chain attacks usually do not attack the final system directly. They attack the trust path that the system depends on.

Attack surface	Common examples	Core risk
Dependency packages	npm, PyPI, Maven, Go modules	A malicious package is installed while appearing to be a legitimate dependency.
Maintainer accounts	npm owners, PyPI maintainers, GitHub permissions	A malicious version is published using legitimate authority.
CI/CD pipelines	GitHub Actions, GitLab CI, Jenkins	Secrets leak, artifacts are tampered with, or release privileges are abused.
Package registries	npm registry, PyPI, container registries, internal mirrors	The artifact distributed by the registry differs from the source in the Git repository.
Update channels and install scripts	Signed installers, auto updaters, postinstall hooks, `setup.py`	Arbitrary code runs during installation or update.
Runtime environments	Egress, shell execution, credential access	The compromised software contacts C2 infrastructure, leaks secrets, or enables lateral movement.

What makes these attacks dangerous is that everything can look like a normal process. Developers install packages as usual. CI builds as usual. Deployment systems publish artifacts as usual. If one part of that ordinary path is compromised, malicious code can flow downstream naturally.

Case Study

Supply chain attacks are not new, but recent incidents make it easier to see where attackers are focusing. The table below gives the broad pattern first, followed by a short explanation of each case.

Year	Incident	Trust path targeted by the attacker	Key lesson
2021	Kaseya VSA	Remote management and deployment tools	Management tools carry large-scale deployment authority, so compromise can cascade into customer environments.
2022	PyTorch nightly `torchtriton`	Package names and registry priority	Namespaces and dependency resolution rules are security boundaries.
2023	3CX DesktopApp	Signed update channel	Signed updates still require verification of the build environment and distribution path.
2024	XZ Utils	Release tarballs and distributed artifacts	A Git repository and the artifact users install can differ.
2025	`tj-actions/changed-files`	Third-party GitHub Action	Even small CI utilities can see secrets and tokens.
2026	axios npm compromise	npm registry and publish account	A registry package can be compromised even when the GitHub repository looks clean.

#1. Kaseya VSA — Management Tools as Attack Path (2021)

The Kaseya VSA ransomware incident showed how dangerous remote management and deployment tools can be as trust boundaries. In July 2021, CISA issued an alert about a supply-chain ransomware attack affecting multiple MSPs using Kaseya VSA. Once a management tool is compromised, damage can spread beyond one server into many customer environments connected through MSP operations.

#2. PyTorch Nightly — Name and Index Priority (2022)

This incident is a classic example of dependency confusion. The PyTorch Foundation reported that, between December 25 and December 30, 2022, Linux users who installed PyTorch-nightly through pip could receive a malicious PyPI package for the torchtriton dependency. The package name that should have resolved from an internal nightly index also existed on public PyPI, and the public index took priority.

Package names, namespaces, and registry priority are not just configuration details. If those boundaries fail, a normal installation path becomes an attack path.

#3. 3CX — Signed Updates Need Verification (2023)

The 3CX DesktopApp incident involved a compromised signed desktop application update. Mandiant analyzed the intrusion as having started from a prior software supply chain compromise. In other words, the 3CX internal environment was first infected through another compromised software package, and then compromised 3CX software was delivered onward to 3CX customers.

A signed update matters, but it is not enough. We still need to understand what environment produced the update, what workflow it went through, and what the software does after execution.

#4. XZ Utils — Clean Repo, Different Artifact (2024)

The XZ Utils backdoor incident made one point especially clear: manually inspecting a source repository is not the same as verifying the package that users actually install. OpenSSF summarized CVE-2024-3094 as a backdoor in the xz package, with affected versions 5.6.0 and 5.6.1.

What users ultimately install is not the code shown on a web page. It is a release artifact produced by a build and release process. That is why reproducible builds, provenance, tarball verification, and artifact comparison matter.

#5. tj-actions/changed-files — Small CI Tools See Secrets (2025)

In March 2025, a major supply chain attack also hit the GitHub Actions ecosystem. According to NVD’s description of CVE-2025-30066, tags from v1 through v45.0.7 of tj-actions/changed-files were changed between March 14 and March 15, 2025, to point to malicious commit 0e58ed8. As a result, secrets could be exposed through GitHub Actions logs. StepSecurity also analyzed the Action as creating a risk of exposing CI/CD secrets in public build logs.

The core lesson is that a reference such as uses: owner/repo@v1 is a weaker trust boundary than it may appear. Tags can move. Third-party Actions run as code inside the runner. They may see the secrets and GITHUB_TOKEN permissions granted to the job. This is why GitHub recommends pinning third-party Actions to full-length commit SHAs. But SHA pinning is not the entire answer. Workflow permissions should be minimized, PR validation jobs should be separated from release and publish jobs, and any Action running in a job with secrets should be tightly controlled.

#6. axios — Registry Compromise Alone (2026)

Returning to axios, the incident answers a practical question: can an npm package be compromised even if the GitHub repository looks fine?

Microsoft reported that malicious axios versions 1.14.1 and 0.30.4 were identified on March 31, 2026, and that both used plain-crypto-js@4.2.1 to perform install-time code execution and distribute a C2-based second-stage RAT.

Datadog noted that axios@1.14.0 had been published through GitHub Actions OIDC trusted publishing, while the malicious 1.14.1 version was published directly from a compromised account and lacked trusted publisher metadata. GitLab Advisory also listed the affected versions and the safe downgrade versions, 1.14.0 and 0.30.3.

The key lesson is not only that specific versions were malicious. The broader lessons are:

The source repository and the package registry are not the same thing.
A malicious version published through a legitimate account is hard to stop by trusting “official packages” alone.
A new runtime dependency in a patch release is a strong anomaly signal.
Publish identity, provenance, Git tags, and trusted publishing metadata are important security signals.

Vulnerable Code, Vulnerable Trust

Traditional security thinking often treats vulnerabilities as something inside code: input validation failures, authentication bypasses, SSRF, XSS, memory errors, and so on. Those still matter.

But in supply chain attacks, the vulnerability may live in the process and trust structure rather than in one line of application code.

A package with a similar name is installed by mistake.
A public package with the same name as an internal package wins because it has higher resolution priority.
A maintainer account is compromised and used to publish a malicious version with legitimate authority.
A CI secret leaks and lets an attacker run a release workflow.
The Git tag looks normal, but the artifact uploaded to the registry is different.
An install script downloads an external payload at install time.
A build runner sends secrets to an external endpoint.

In these cases, “Does our application code have a bug?” is not enough. The deeper problem is that we trust too much, for too long, and too implicitly.

Modern supply chain security is not about eliminating trust entirely. That is unrealistic. It is about shortening trust, attaching evidence to it, and automating verification at each step.

Beyond SCA and SBOM

When people talk about supply chain security, Software Composition Analysis, or SCA, is often the first tool that comes to mind. SCA is useful for identifying open source components and known vulnerabilities. It is necessary for managing CVEs, license risk, and vulnerable dependency versions.

But the main question SCA asks is:

Does this version have a known vulnerability?

Supply chain attacks require additional questions:

Was this version published through the expected process?
Was this artifact produced by a workflow we trust?
Did this package suddenly add a new runtime dependency?
What code does this package execute during installation?
Does it make unexpected outbound connections after execution?

SBOMs have the same limitation. A Software Bill of Materials is an inventory of what is inside the software. CISA and NTIA materials treat SBOMs as an important way to improve component visibility, but an SBOM does not, by itself, decide whether something is safe.

Item	Question it answers	Limitation
SCA	Does this component have known vulnerabilities?	It can miss newly published malicious versions or maintainer account compromise.
SBOM	What is included?	It is an inventory, not a safety judgment.
VEX	Does this vulnerability actually affect the product?	It requires accurate product context and operational process.
Provenance	Who built this, and through what process?	It requires verification policies and enforcement during deployment.
Attestation	Was that claim recorded in a verifiable form?	Its value is limited if signatures and policies are not actually verified.
Runtime monitoring	What did the software actually do after execution?	It is closer to detection and response than prevention.

Supply chain security has to combine these questions. No single tool solves every trust problem.

A Zero Trust Lens

Zero Trust is not merely a slogan that says, “Do not trust the internal network either.” NIST SP 800-207 describes zero trust as a security paradigm that shifts defenses away from static network perimeters and toward users, assets, and resources. It also states that trust should not be granted implicitly based only on network location or asset ownership.

Applied to software supply chains, that means the following:

Zero Trust principle	Application to supply chain security
Verify explicitly	Verify dependencies, artifacts, publishers, provenance, and attestations at each stage.
Least privilege	Give CI tokens, registry tokens, cloud roles, and runner permissions only what each job needs.
Assume breach	Design controls as if maintainer accounts, build runners, registries, or update channels may already be compromised.
Continuous monitoring	Watch publish metadata changes, sudden dependency additions, install-time behavior, and runtime egress.

From this perspective, assumptions like “It is our internal CI, so it is fine,” “It is an official npm package, so it is fine,” or “There is a GitHub release, so it is fine” are no longer sufficient. CI needs verification. Registries need verification. Release artifacts need verification. Post-install and runtime behavior also need verification.

In supply chain security, Zero Trust can be summarized like this:

Shorten trust, attach evidence, and automate verification.

Where to Start

Supply chain security is a broad field. It is difficult to adopt every control at once. A practical approach is to prioritize.

P0 — Basic Controls Now

Enforce lockfiles and reproducible installation. Reduce dependency tree drift and make CI installation results predictable.
Review dependency diffs at the PR stage. Check new direct and transitive dependencies, known vulnerabilities, licenses, and runtime dependency changes before merge.
Apply a cooldown for newly published releases. This reduces the risk of automatically installing a version immediately after publication, before the ecosystem has had time to detect or retract it. Examples include npm’s min-release-age, Dependabot’s cooldown, and Renovate’s minimumReleaseAge, applied as release-age gates in CI and dependency update bot policies.
Reduce long-lived publish tokens and use OIDC. Lower the risk of long-lived token theft by granting permission only to specific workflows and environments.
Minimize GitHub Actions permissions and use SHA pinning. Avoid relying on movable tags or overly broad GITHUB_TOKEN permissions.
Record artifact provenance and attestations. The goal is not just to know that “CI passed,” but to verify that the artifact came from the expected build path.

P1 — Operational Maturity

Operate SBOM and VEX together. SBOMs provide component inventories, while VEX helps determine whether a vulnerability actually affects a product.
Isolate self-hosted runners. Runners that execute untrusted PRs should be separated from release and publish runners that have access to secrets.
Monitor registry and publish metadata. Unexpected publishers, absence of trusted publishing metadata, registry-only versions without Git tags, and new runtime dependencies in patch releases are all useful anomaly signals.
Observe install-time and runtime egress. Where possible, apply deny-by-default egress allowlists. At minimum, detect suspicious domain access, shell execution, or downloader behavior.

P2 — Long-Term Maturity

Improve build maturity with SLSA. The core idea is to gradually improve build provenance, tamper resistance, and build integrity.
Include supplier security in procurement criteria. Evaluate SBOM availability, vulnerability disclosure processes, secure development practices, release provenance, log availability, and incident response cooperation.
Automate metadata-based anomaly detection. Package publish events, maintainer changes, new dependencies, missing provenance, and Git tag mismatches can be connected to SIEM or internal monitoring for faster detection.

Team Checklist

Dependency Management

Is the lockfile committed to the repository?
Does CI use reproducible installation methods such as npm ci, pip --require-hashes, or go mod verify?
Are dependency diffs reviewed in PRs?
Is separate approval required when a patch or minor release adds a new runtime dependency?
Are package managers and dependency update bots configured with a cooldown so newly published releases are not installed immediately?
Are internal package namespaces managed so they do not collide with public registries?

CI/CD

Are token permissions minimized per workflow?
Are third-party GitHub Actions pinned to full-length commit SHAs?
Are release and publish jobs separated from PR validation jobs?
Are self-hosted runners isolated from untrusted PR execution?
Does cloud deployment use OIDC instead of long-lived secrets?

Package Publishing and Registries

Is OIDC-based publishing, such as npm trusted publishing, in use?
Have long-lived publish tokens been removed, expired, or scoped down?
Are private: true, publishConfig.registry, and scoped registry policies used where appropriate?
Are registry signatures or provenance verified?
Is publisher identity and metadata drift monitored?

Artifacts and Deployment

Do build artifacts include provenance or attestations?
Are artifact attestations verified before deployment?
Is an SBOM generated and stored with the artifact?
Is VEX or a similar impact assessment process in place?

Runtime

Is outbound traffic from build runners and applications observed?
Can a deny-by-default egress policy or allowlist be applied?
Is suspicious behavior such as shell execution, curl, wget, or PowerShell during installation detected?
Is there a procedure for secret rotation and runner forensics after a supply chain incident?

Closing

The phrase “axios compromised on npm” did not read like a story about one library. It was a reminder to re-examine the entire development process we trust every day.

The danger of supply chain attacks is that they use normal paths. Attackers can make malicious code look like a normal update, a normal package, or a normal release. That makes these attacks hard to detect and respond to, and once they succeed, the damage can spread widely to downstream users and customers.

Supply chain security is no longer just about asking, “Which package is vulnerable?” We also need to ask where the package came from, who published it, which workflow produced it, whether the release metadata matches expectations, and what the software does during installation and execution.

Modern supply chain security has to combine SCA, SBOM, provenance, CI/CD hardening, and runtime monitoring. That direction aligns naturally with Zero Trust principles.

The goal is not to eliminate trust. It is to shorten trust, attach evidence to it, and verify it automatically. That is a practical starting point for modern software supply chain security.

References

NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations: https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final
NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines: https://www.nist.gov/publications/strategies-integration-software-supply-chain-security-devsecops-cicd-pipelines
NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final
CISA, Kaseya VSA Supply-Chain Ransomware Attack: https://www.cisa.gov/news-events/alerts/2021/07/02/kaseya-vsa-supply-chain-ransomware-attack
PyTorch Foundation, Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022: https://pytorch.org/blog/compromised-nightly-dependency/
Mandiant / Google Cloud, 3CX Software Supply Chain Compromise Initiated by a Prior Software Supply Chain Compromise: https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise
OpenSSF, xz Backdoor CVE-2024-3094: https://openssf.org/blog/2024/03/30/xz-backdoor-cve-2024-3094/
NVD, CVE-2025-30066: https://nvd.nist.gov/vuln/detail/CVE-2025-30066
StepSecurity, tj-actions/changed-files action is compromised: https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised
GitHub Docs, Security hardening for GitHub Actions: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions
GitHub Docs, Artifact attestations: https://docs.github.com/en/actions/concepts/security/artifact-attestations
npm Docs, Trusted publishing for npm packages: https://docs.npmjs.com/trusted-publishers
npm Docs, About ECDSA registry signatures: https://docs.npmjs.com/about-registry-signatures/
npm Docs, npm ci: https://docs.npmjs.com/cli/v11/commands/npm-ci
npm Docs, min-release-age config: https://docs.npmjs.com/cli/v11/using-npm/config#min-release-age
GitHub Docs, Dependabot cooldown options: https://docs.github.com/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
Renovate Docs, Minimum Release Age: https://docs.renovatebot.com/key-concepts/minimum-release-age/
CISA, Software Bill of Materials (SBOM): https://www.cisa.gov/sbom
NTIA, The Minimum Elements For a Software Bill of Materials (SBOM): https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom
OpenSSF, SLSA: https://openssf.org/projects/slsa/
Microsoft Security Blog, Mitigating the Axios npm supply chain compromise: https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/
GitLab Advisory Database, GHSA-fw8c-xr5c-95f9: https://advisories.gitlab.com/npm/axios/GHSA-fw8c-xr5c-95f9/
Datadog Security Labs, Compromised axios npm package delivers cross-platform RAT: https://securitylabs.datadoghq.com/articles/axios-npm-supply-chain-compromise/