How to protect your company from software supply chain attacks

Open source dependencies power virtually every modern application. And yet most teams pull them directly from the public registry, trusting that what they install is what was reviewed, audited, and intended to ship. In 2026, that assumption has become untenable.

Supply chain attacks - where attackers compromise a trusted package rather than building a fake one - have become the dominant threat vector in software security. This guide covers what they are, how they work, what your company should do to prepare, and which tools and vendors can actually help.

Key Takeaways

1. Modern supply chain attacks target trusted packages, not fake ones. The shift from typosquatting to compromising legitimate maintainers and pipelines means traditional package hygiene is no longer sufficient protection.
   
2. CI/CD pipelines are the primary target. Attackers increasingly bypass stolen tokens entirely - compromising the build environment so they can publish malicious code through legitimate, trusted infrastructure.
   
3. Signing, provenance, and OIDC are necessary but not sufficient. Once an attacker controls the CI environment, they inherit its trust. A signed artifact with valid provenance can still be malicious if the signing environment was compromised.
   
4. The right defense is proactive, not reactive. Scanners that flag issues after packages arrive can only catch known threats. A vetted artifact source blocks malicious versions before they're ever available to pull - which is the only reliable defense against novel, trusted-package compromises.
   
5. Echo Libraries provides a pre-secured, continuously maintained source for npm and PyPI packages - with malware sandboxing, automatic CVE remediation, upstream health monitoring, and zero workflow disruption. When the axios npm supply chain attack hit, Echo customers were unaffected.
   

What is a software supply chain attack?

A software supply chain attack targets the tools, dependencies, and infrastructure used to build software - rather than the application itself. Instead of trying to breach your perimeter, attackers compromise something your environment already trusts: a widely used open source package, a CI/CD pipeline, or a build system.

The pattern is consistent across nearly every major incident:

• A maintainer account is compromised - via infostealer malware, phishing, or social engineering
• A malicious version is published under the legitimate package name, often through the project's own CI/CD pipeline
• Automated systems pull it everywhere - because that's exactly what they're designed to do
• Credentials and secrets are silently exfiltrated - SSH keys, cloud credentials, Kubernetes configs, npm tokens, GitHub secrets

What makes this threat so effective is that nothing looks wrong from the outside. The package name is correct. The publisher may be legitimate. The artifact may even be signed. The trust signals all check out - because the attacker has inherited the same trust as the pipeline itself.

Why software supply chain attacks are increasing in 2026

The scale of recent incidents makes the trend impossible to ignore. Within a short window in 2026, the following widely trusted packages were all compromised using the same underlying playbook:

• TanStack - a React ecosystem with millions of weekly downloads, hit via chained CI/CD vulnerabilities and OIDC token hijacking. No passwords or tokens were stolen; attackers hijacked the trusted publishing pipeline directly.
• Axios (npm) - a package with ~100 million weekly downloads. Attackers published malicious versions 1.14.1 and 0.30.0 after gaining access to publishing infrastructure. No corresponding GitHub tag, no build attestations, publisher changed to a manual account.
• Mistral (PyPI) - a malicious version executed credential-stealing code on Linux import, with logic to wipe systems on certain geographic configurations.
• Red Hat Cloud Services - more than 30 official npm packages compromised through Red Hat's own legitimate CI/CD pipeline, affecting over 100,000 weekly downloads. Attackers used a compromised developer account to inject malicious GitHub Actions workflows and publish backdoored packages using OIDC trusted publishing.
• LiteLLM (PyPI) - a malicious version published from a compromised maintainer account, silently exfiltrating environment variables, cloud credentials, and API keys on Python startup.

Over 500 million combined downloads across affected packages. In each case, the package was trusted. The attack succeeded because that trust was warranted - and then abused.

The deeper driver is structural: open source is the world's largest shared execution surface. If you want reach at scale, you don't target individual companies - you target what they all depend on. And automated dependency management, the same feature that keeps development teams productive, is what gives supply chain attacks their propagation speed. The axios npm supply chain attack alone resulted in approximately 1.8 million malicious downloads.

What features should a supply chain security solution have?

When evaluating how to protect your company, look for solutions that address the threat before packages reach your environment - not just after. Specifically:

1. Malware prevention before installation Every library version should be sandboxed and analyzed before it's available to install. This catches malicious install scripts, post-install hooks, and obfuscated payloads - the techniques used in the Mistral, LiteLLM, and Shai-Hulud attacks.

2. Automatic vulnerability remediation Critical and high CVEs should be patched on the exact version your application requires - without forcing dependency tree changes. This eliminates the scanner-alert → ticket → manual upgrade cycle.

3. Upstream maintainer and project health monitoring Changes in publisher accounts, unusual release cadences, or new contributors with elevated permissions are early signals of compromise. A strong solution monitors these continuously and quarantines anomalies before they propagate.

4. Verified provenance and cryptographic signing You should be able to prove that what you installed was built from the source it claims to represent - using infrastructure that an attacker couldn't access through the original maintainer's pipeline.

5. SBOM and VEX documentation Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) documents provide audit-ready evidence of what's in your build, what vulnerabilities exist, and which have been remediated.

6. Zero developer workflow disruption The best solutions use the same package names, versions, and install commands your engineers already use. Security should be invisible in the development flow - but fully active at every pull.

7. Integration with existing repository infrastructure Mirroring into Nexus, JFrog Artifactory, GitHub Packages, or other internal repositories is essential for enterprise adoption without re-architecting pipelines.

Which Companies Provide Secure npm and Python Libraries?

The market for hardened, pre-secured library infrastructure is still relatively new. Most traditional security vendors focus on scanning and alerting after packages arrive in your environment. Only a small number provide a vetted artifact source that prevents malicious versions from being available to pull in the first place.

Echo

Echo Libraries is the most complete solution for teams that need a trusted, vetted source for npm and PyPI packages - as well as Java JARs, Ruby gems, and Go modules. Rather than scanning post-installation, Echo provides a continuously maintained artifact pipeline where malicious and vulnerable versions are blocked before they're ever available to your environment.

Key capabilities:

• Internal malware sandboxing on every library version
• Automatic remediation of critical and high CVEs on the same version you depend on
• Continuous upstream project and maintainer health monitoring
• Libraries built on Echo's own secure infrastructure, signed and attested
• SBOM and VEX delivery for audit and compliance readiness
• Zero changes to developer workflow or dependency tree
• Mirrors into Nexus, JFrog Artifactory, GitHub Packages, Quay, and custom repositories
• Recognized clean by all major scanners: Trivy, Grype, Snyk, Wiz, Orca, Aqua, and more

When the axios npm supply chain attack occurred, Echo customers were completely unaffected. Their environments never saw the compromised versions.

Alternatives and Adjacent Approaches

Other vendors take related but narrower approaches:

• Socket.sh - surfaces behavioral risk signals in npm and PyPI packages before they're published. Does not provide a hardened artifact delivery pipeline.
• JFrog Xray - deep scanning of artifacts already in JFrog Artifactory. Detects issues after arrival; does not prevent malicious versions from being pullable.
• Snyk - developer-focused vulnerability scanning with strong CI/CD integration. Alerts on known CVEs but does not remediate them or replace the artifact source.
• GitHub Dependabot - alerts on vulnerable dependencies and opens PRs for upgrades. Does not harden the artifact itself.

The key distinction: most tools in this space are scanners. Echo is a secured artifact source. Scanners can only catch what they know to look for. A vetted source ensures the artifact is clean before you ever install it - which is the only reliable defense when the threat is a malicious version of a trusted package.

Why signing and provenance alone aren't enough

It's worth addressing a common misconception directly. For years, the industry's answer to supply chain security was: use trusted publishing, sign your artifacts, require attestations. Those controls still matter. But recent attacks have demonstrated their limits.

In the TanStack and Red Hat incidents, the artifacts were signed. The provenance was valid. The publishing workflow was legitimate. The packages were still malicious - because the attacker had access to the CI environment that generated those guarantees.

Signing proves where something was built. It doesn't prove the build environment was clean. Once attacker-controlled code is executing inside the CI environment, it inherits the same trust as the pipeline itself. That's why controlling what enters your build environment - through a secured, independently verified artifact source - is becoming essential alongside, not instead of, signing and attestation.

For a deeper look at the specific incidents that exposed this pattern, see our analysis of the March 2026 supply chain attacks, covering the Trivy, LiteLLM, and Axios compromises in detail. And for how this threat extends to infrastructure vulnerabilities, see CVE-2026-7482: the critical Ollama vulnerability.

FAQ

What is a software supply chain attack?

A software supply chain attack targets the tools, packages, and infrastructure used to build software rather than the application itself. Attackers compromise a trusted package maintainer, CI/CD pipeline, or build system to inject malicious code into a legitimate update. Because the package appears to come from a trusted source and is distributed automatically, the attack can propagate into thousands of environments before anyone detects it - often silently exfiltrating credentials and secrets in the process.

Why are supply chain attacks so hard to detect?

Because the threat comes from a trusted source. When a malicious version of axios, Mistral, or TanStack is published under the legitimate package name - potentially with valid signatures and provenance - nothing in your normal dependency workflow raises a flag. Standard scanners look for known CVEs or known malware signatures. An attack using a novel payload in a freshly compromised trusted package may not match any existing rule. The only reliable defense is controlling what versions are ever available to your environment in the first place.

How should companies prepare for supply chain attacks?

The most effective preparation combines a vetted artifact source with strong CI/CD hygiene. On the artifact side: use a provider like Echo that sandboxes, verifies, and attests packages before making them available, so malicious versions never enter your pipelines. On the pipeline side: pin dependencies to digests rather than tags, audit unusual publisher changes, monitor for anomalous release patterns, and rotate credentials immediately if you suspect exposure. Treat any environment that ran an unvetted install during a known attack window as potentially compromised.

What is the difference between a hardened npm package and a regular one?

A regular npm package is pulled directly from the public registry, where it's published by the maintainer with no independent verification. A hardened npm package has been processed through a controlled pipeline that includes malware sandboxing, vulnerability remediation, provenance verification, and cryptographic signing - by a trusted intermediary whose infrastructure is independent of the original maintainer's. The result is the same package name and version your engineers expect, but with security guarantees the public registry cannot provide.

How does Echo Libraries protect against supply chain attacks?

Echo Libraries provides a continuously maintained, vetted artifact source for npm, PyPI, and other ecosystems. Every package version is sandboxed for malicious behavior before it's available to install. Upstream maintainer and project health is monitored continuously for compromise signals. Libraries are built and attested on Echo's own secure infrastructure, separate from original maintainer pipelines. When the axios npm supply chain attack occurred - impacting ~100 million weekly downloads - Echo customers were completely unaffected because the compromised versions were never available in their artifact source.