How the ChainDrop npm supply chain attack demonstrates the difference between software provenance and software trust.
The latest Shai-Hulud campaign, widely referred to as ChainDrop, is a reminder that software supply chain attacks have entered a new phase.
According to BleepingComputer’s report, the campaign compromised more than 1,300 npm packages, including widely used projects such as Keyv, Cacheable, flat-cache, and file-entry-cache. Collectively, these packages account for an estimated 2 billion monthly downloads, making it one of the largest npm supply chain attacks seen in recent years.
Those numbers are significant, but the real story isn't the scale of the attack. It's what the attack tells us about how software trust is evolving.
Unlike traditional attacks that exploit software vulnerabilities, the latest Shai-Hulud campaign targeted the trust relationships behind modern software development. Instead of breaking npm or bypassing security controls, the attackers compromised trusted maintainers, abused legitimate publishing workflows, and distributed malicious software through channels developers already relied upon.
That distinction has important implications for every engineering team consuming open-source software.
The Attack Was Designed to Inherit Trust
The success of the latest Shai-Hulud campaign wasn't driven by a vulnerability in npm itself. It was driven by the attackers' ability to inherit trust.
Once legitimate maintainer accounts were compromised, malicious versions of packages were published through standard npm release workflows. These packages executed malicious code during installation using npm lifecycle hooks such as preinstall, allowing code to run before developers ever interacted with the package itself.
From there, the malware harvested credentials from developer workstations and CI/CD environments, including GitHub authentication tokens, npm authentication tokens, and other credentials available to the compromised environment. Those stolen identities were then used to publish additional malicious package versions, allowing the campaign to propagate across the ecosystem through legitimate publishing channels.
As documented in analyses by StepSecurity and Palo Alto Networks Unit 42, this behavior transformed the compromise from a single malicious package into a self-propagating software supply chain attack, enabling attackers to expand their reach by abusing trusted maintainer identities and legitimate publishing workflows.
The objective wasn't simply to distribute malware. It was to compromise trusted publishers, inherit their reputation, and use that trust to compromise additional software consumers.
For downstream developers, very little appeared unusual. Dependencies resolved successfully. Package installation completed normally. Releases came from familiar projects. From the package registry's perspective, the software appeared authentic because it was published through legitimate maintainer identities.
Shai-Hulud Didn't Break Provenance. It Exposed Its Boundaries.
Incidents like this naturally raise questions about software provenance, artifact signing, and modern software supply chain frameworks.
If malicious software can still reach developers, did those controls fail?
The answer is no.
Software provenance is designed to establish the origin and integrity of software artifacts. It helps engineering teams answer questions such as:
- Which source repository produced this artifact?
- Which build workflow generated it?
- Which identity signed it?
- Has the artifact been modified after it was built?
These guarantees remain foundational to modern software supply chain security.
However, software provenance and software trust answer fundamentally different questions.
If an attacker gains access to a trusted maintainer account or compromises a legitimate publishing workflow, the resulting artifact may still carry valid provenance because it genuinely originated from an authorized identity using an authorized build process.
This illustrates an important distinction: provenance establishes the authenticity of an artifact's origin and build process, while trust requires an independent decision about whether that software should be introduced into your environment. This distinction has also been highlighted in research from Endor Labs.
In other words, provenance establishes authenticity, but it doesn't determine whether the software should be trusted.
Provenance answers, "Can I verify where this software came from?"
Trust answers, "Should I allow this software into my environment?"
Those are closely related questions, but they are not the same.
We explored this distinction in our earlier article, Understanding Image Provenance, which explains how provenance establishes the origin and integrity of software artifacts and why it remains a foundational component of modern software supply chain security.
Visibility Is No Longer Enough
The latest Shai-Hulud campaign also reinforces another trend we've written about previously.
In Modern npm Supply Chain Attacks Beat CVE Scanners and SBOMs, we discussed why visibility alone cannot stop today's dependency attacks. Knowing which components exist within an application is essential, but an SBOM or dependency inventory cannot determine whether a trusted package has become malicious before it enters your build process.
Engineering teams increasingly assemble applications from hundreds of external libraries, frameworks, build tools, and AI-generated recommendations. Every dependency represents a trust decision.
Software supply chain security can no longer begin after software has already been downloaded. It needs to begin before software is adopted into the build process.
Engineering teams should evaluate third-party software before introducing it into their build pipelines, protect developer identities and CI/CD systems as critical infrastructure, reduce unnecessary dependency chains wherever possible, and continuously reassess the trustworthiness of the software entering production.
These practices do not replace provenance or SBOMs.
They complement them.
The Next Challenge for Software Supply Chains
The software industry has made remarkable progress over the past few years.
Over the past few years, the industry has made significant progress in strengthening software supply chains. SBOMs have improved visibility, software provenance has strengthened confidence in build integrity, and artifact signing together with reproducible builds has made software delivery pipelines significantly more transparent.
The latest Shai-Hulud campaign does not diminish that progress
The latest Shai-Hulud campaign does not diminish that progress. Instead, it reminds us that software supply chain attacks are evolving. Attackers are increasingly targeting the trust behind software rather than the software itself. As organizations consume more open source components and AI accelerates software development, proving where software came from is no longer the finish line. It is the starting point.
It is the starting point.
The next challenge is establishing confidence in the software before it becomes part of our applications.
That is the difference between software provenance and software trust, and it is a distinction engineering teams can no longer afford to overlook.
