On April 23, 2026, @bitwarden/cli was compromised as part of the ongoing Checkmarx supply chain campaign. Malicious code was injected into version 2026.4.0 via a GitHub Actions workflow in Bitwarden's own CI/CD pipeline. The package had 9 maintainers, nearly 78K weekly downloads, and a behavioral trust score of 92 out of 100.

Three days later, this is still being discussed as a "supply chain attack" — which is accurate but flattening. The category is real. The mechanism is completely different from the ua-parser-js attack in 2021, and the defenses that would have helped are mostly non-overlapping. That distinction matters if you're trying to actually protect your dependencies rather than check a compliance box.

Category 1: Credential compromise

In October 2021, ua-parser-js was compromised. The package had roughly 8 million weekly downloads and a single maintainer. Attackers phished that maintainer's npm credentials and published three malicious versions in quick succession. The packages dropped a cryptominer and a credential harvester. CVE-2021-4229 followed.

npm audit showed zero issues before the attack. The vulnerability was structural, not in the code — a package with massive download volume and one person holding the publish key.

This is the credential compromise pattern: the attack succeeds because the identity of the person who can publish is concentrated. One phishing email, one compromised account, one malicious publish. The blast radius is determined by how many projects pull the package.

Axios is the current example to watch. Roughly 100 million weekly downloads. One maintainer. Same structural profile as ua-parser-js before the attack — concentrated publish authority over an enormous install base.

Category 2: Build pipeline compromise

The Bitwarden attack is structurally different. There was no phished maintainer. The organization is real, the team is real, the 7+ year release history is real. Attackers didn't need to compromise a person — they compromised the build environment.

A GitHub Action in Bitwarden's CI/CD pipeline was tampered with. That action ran during a legitimate release, injected malicious code into the published artifact, and the package landed on the registry with Bitwarden's legitimate credentials. From the registry's perspective, nothing was wrong. From a behavioral scoring perspective, nothing was wrong. The package was published by its real maintainers, from their real account, as part of a real release process.

What was compromised wasn't an identity. It was the chain of custody between source code and published artifact.

What structural scoring catches

proof-of-commitment scored @bitwarden/cli at 92/100 before this attack. That score was correct. Nine maintainers, consistent release history, strong download momentum, GitHub-backed organization — all genuine signals that the package is well-managed and not structurally fragile.

What behavioral scoring detects is the structural conditions that make credential compromise likely and high-impact:

• Single maintainer with high download volume (ua-parser-js, axios)
• No organizational backing — one person's npm account is the only barrier
• Stale packages still pulled by millions of projects
• Brand-new packages with zero history impersonating legitimate ones

It does not detect whether the build pipeline that published a well-maintained package was tampered with. That's a different threat surface.

What catches build pipeline attacks

The npm ecosystem has a real answer for this: build provenance. Since 2023, npm supports provenance statements — cryptographically signed attestations that link a published package to a specific source repository, commit, and build environment. When provenance is present, you can verify that a given version was built from a specific commit in a specific GitHub Actions run.

A compromised action that injects code during the build produces a package that doesn't match the source. That breaks the provenance chain. npm audit signatures checks this.

npm audit signatures

Beyond provenance, the broader SLSA framework (Supply-chain Levels for Software Artifacts) provides a graduated set of requirements for build integrity — from basic provenance at SLSA 1 up to hermetic, reproducible builds at SLSA 3 and 4. SLSA 3 would require that the build environment itself be hardened against tampering, which is the category the Bitwarden attack falls into.

Tools like Socket.dev scan new publishes in real time for malicious code patterns — another layer that catches active injection, not structural risk.

The two categories, side by side

There's a third column worth adding: real-time publish scanning (Socket, Snyk) catches both, but after the fact — it detects malicious code in a published version, not before it lands in a lockfile.

What the Bitwarden attack doesn't invalidate

The argument I've seen today is that the Bitwarden attack proves structural scoring is useless because a well-scored package got compromised. This is wrong in a specific way.

A package with 9 maintainers and a 7-year release history is genuinely harder to compromise via credential phishing than a package with one maintainer and no organizational backing. That's not a scoring artifact — it's real. ua-parser-js was attacked via its sole maintainer. Attacking Bitwarden required a more sophisticated pipeline compromise because the credential vector was too hardened.

The structural score measures one threat surface accurately. It doesn't cover all threat surfaces. That's not a flaw in the tool — it's a scope boundary. Knowing the scope is how you build the right layered defense.

The stack that actually works

Defense against npm supply chain attacks requires layers that cover different threat surfaces:

1. Structural scoring (proof-of-commitment) — identify concentration risk before an attack; catch sole-maintainer packages before they become ua-parser-js
2. Provenance verification (npm audit signatures) — verify that published artifacts match their source builds; catches pipeline tampering
3. Real-time publish scanning (Socket, Snyk) — detect malicious code patterns in new releases as they land
4. Lock file pinning — don't pull new versions automatically; create a window to catch anomalies before they reach production

Each layer has a blind spot. The blind spots don't overlap much. Running all four means the attack scenarios with no defense become significantly fewer.

# Check structural risk
npx proof-of-commitment --file package.json

# Check build provenance
npm audit signatures

These answer different questions. Both answers matter.

proof-of-commitment is open-source and free. Web audit · API docs