Behavioral Risk Brief: ChainDrop
The Claim
Governance frameworks that treat verified build provenance as proof of safety create systemic risk when an artifact can carry a fully valid provenance record and still execute malicious
behavior. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package actually does, independent of whether its provenance chain is intact and verifiable.
The Incident
Microsoft Threat Intelligence identified a large-scale, self-propagating npm supply chain attack, tracked as ChainDrop, affecting more than 400 packages across multiple unrelated publishers,
including packages in the keyv, flat-cache, and cache-manager ecosystems. BleepingComputer reported the campaign began after a threat actor compromised the GitHub account belonging to keyv’s maintainer, then spread to packages from other organizations entirely. According to Microsoft, the initial malicious releases were published through the compromised projects’ own legitimate build process, while stolen npm tokens were also used to modify additional packages directly, leaving no corresponding source commit, pull request, or legitimate release behind them. The malicious releases execute through an npm preinstall hook, and stolen GitHub credentials were used to inject configuration files into repositories.
The Governance Failure
The governance failure is not that a widely used package was compromised, but that verified build provenance, was present and technically accurate, and it still provided no protection. Provenance confirms that an artifact was built by the process it claims to have been built by. It says nothing about what that process was directed to do, which is exactly the layer this campaign operated in.
This is compounded by how the compromise reached the build pipeline in the first place. The attacker did not forge a provenance record or bypass the verification chain, they used the project’s own legitimate automation to produce a release that was authentic by every existing measure. Any organization relying on provenance verification as its primary supply chain control would have found nothing to flag, because nothing about the verification process itself failed.
The underlying breakdown is the absence of a trust decision that evaluates behavior separately from authenticity. As long as an authentic build process is treated as equivalent to safe behavior, an attacker who can reach that process inherits the trust it confers.
The Regulatory and Business Exposure
- Compromise of environments through packages carrying fully valid, verified provenance records.
- Self-propagating spread to packages several dependency layers removed from any direct organizational decision.
- Reliance on provenance verification as a primary control, leaving package behavior itself unexamined.
What Your Auditors Will Ask
- How do you validate package behavior independent of whether its provenance chain is verified and intact?
- What controls detect malicious code introduced through a project’s own legitimate build automation?
- How do you account for risk introduced through dependencies of dependencies your teams never directly selected?
- How do you verify that a preinstall hook’s behavior was evaluated before execution, not assumed safe from a valid build record?
- What evidence do you maintain that provenance verification is treated as one input among several, not as sufficient on its own?
A consistent signal is the disconnect between an artifact’s verified origin and its actual behavior once installed. A build record confirming how something was made says nothing about what it does when it runs.
Zero Trust for Code Value
Zero Trust for Code introduces a trust decision at the point a package is about to execute, evaluating its behavior directly rather than relying on provenance verification as a substitute for that evaluation. This means a package earns permission to run based on what it does, regardless of how authentic and well-documented its build process appears.
This directly addresses the governance weakness exposed by the initial ChainDrop releases: the assumption that a verified provenance chain is equivalent to safe execution. By requiring a pre-execution trust decision independent of build authenticity, organizations can evaluate what a preinstall hook actually does, even when the package delivering it was produced through an entirely legitimate and verifiable process.
The result is a governance model where provenance and behavior are assessed as separate questions, closing the space this campaign relied on when it turned a project’s own trusted automation into a distribution mechanism.
Governance Action Brief
- Establish governance controls that evaluate package behavior independently of provenance or build verification status.
- Require a pre-execution trust decision for preinstall hooks and lifecycle scripts, regardless of build authenticity.
- Treat verified provenance as one input among several, not as confirmation that a package is safe to run.
- Monitor for self-propagating compromise spreading through dependency relationships across unrelated maintainers.
- Maintain a record of package behavior evaluated at execution, separate from any provenance or build-chain verification.
Sources
Analysis based on reporting from Microsoft Threat Intelligence and BleepingComputer on the ChainDrop npm supply chain attack, CodeHunter Labs evaluation of governance gaps in provenance-based execution trust, and alignment with NIST 800-53 and NIST SSDF integrity
ChainDrop supply chain compromise: Anatomy of a self-propagating worm | Microsoft Security Blog
