From Bitwarden to SAP: How npm Supply Chain Attacks Are Evolving

Software supply chain attacks are no longer isolated events.

They are becoming patterns.

Over the past few weeks, two incidents involving npm packages have shown how quickly these attacks are evolving. One targeted a widely trusted developer tool. The other reached into an enterprise ecosystem.

Individually, they are concerning.
Together, they reveal something more important.

This is not experimentation.
It is progression.

A Familiar Entry Point: The Bitwarden CLI Compromise

The first incident involved the Bitwarden CLI npm package, a tool developers use to manage secrets securely.

A malicious version of the package was published to npm, embedding code designed to extract credentials from developer environments. Once installed, it could access tokens, environment variables, and configuration data typically available during development or within CI pipelines.

Nothing about the installation process appeared unusual. The package name was correct. The workflow was standard. The trust was implicit.

That is what made it effective.

The attack did not exploit a vulnerability in the tool. It exploited the assumption that the tool itself was safe.

Expanding the Blast Radius: The Mini Shai-Hulud Campaign

Days later, a more advanced variation emerged in the form of the Mini Shai-Hulud campaign.

This time, the attack did not focus on a single package. It targeted multiple npm packages associated with SAP’s development ecosystem.

The malicious code was introduced through preinstall scripts, allowing it to execute during dependency installation. This gave it early access to developer environments, before the application was even built.

From there, it followed a familiar pattern. It extracted credentials, accessed tokens, and attempted to propagate further using available permissions. But the scale and targeting were different.

Instead of compromising a tool, this attack reached into an ecosystem.

Same Playbook, Increasing Impact

At a glance, these incidents may appear separate. They are not.

They share a common structure. A trusted package is distributed through a legitimate channel, and malicious code is executed as part of normal workflows.

What changed is scope.

The Bitwarden incident demonstrated how a single trusted package could be used to extract sensitive data.

The Mini Shai-Hulud campaign showed how that same approach could be expanded across multiple packages, targeting broader environments and increasing the potential impact.

This is not a new technique. It is an evolving one.

The Shift: From Vulnerabilities to Trust Exploitation

Traditional security models are built around vulnerabilities.

They assume software contains flaws, attackers exploit those flaws, and defenses detect and patch them.

These incidents follow a different model.

There is no vulnerability to exploit.

The dependency itself becomes the attack vector.

This shifts the problem from code quality to trust integrity.

Why This Is Harder to Detect

Attacks like these blend into normal development activity.

Developers install dependencies every day. Build systems automatically resolve packages. CI pipelines run scripts as part of standard workflows.

The malicious behavior is not triggered by unusual actions. It is triggered by expected ones.

That makes detection significantly harder.

Vulnerability scanners do not flag them because there is no known CVE. SBOMs list them as dependencies but cannot determine whether they were safe at the time of inclusion. Runtime tools observe behavior after execution, often too late to prevent initial compromise.

The system behaves as designed. The design is what was compromised.

The Real Risk Surface: Build-Time

Both incidents highlight the same critical point.

The attack surface is not just the running application. It is the process that builds it.

When dependencies are pulled directly from public registries, the build pipeline becomes a point of exposure. Every install step is a trust decision.

Once a compromised package enters the system, it becomes part of the environment by default.

By the time runtime controls engage, the damage may already be done.

Rethinking Dependency Trust

If trusted packages can no longer be assumed to be safe, then the way dependencies are consumed needs to change.

This is not about eliminating open source or slowing down development.

It is about reducing blind trust.

That means introducing controls around where dependencies are sourced from, how they are validated before use, whether their contents can be independently verified, and whether builds can be reproduced consistently.

The goal is not to remove all risk. It is to ensure that inclusion is intentional.

What Teams Should Do Right Now

Teams should treat dependency installation as a security-sensitive operation, not just a build step.

In practice, this means reducing direct, unverified pulls from public registries in production pipelines and introducing validation before dependencies are used. It also means monitoring for unexpected changes in upstream packages, even when version pinning is in place.

These steps do not eliminate risk entirely. But they significantly reduce blind trust in how software is assembled and make it harder for compromised dependencies to enter unnoticed.

A Pattern, Not an Exception

The progression from the Bitwarden CLI compromise to the Mini Shai-Hulud campaign is not random.

It reflects a broader shift in how attacks are being executed.

Start with a single high-trust package.
Validate the approach.
Expand into ecosystems.

The pattern is clear.

What begins as a targeted compromise can quickly evolve into a systemic risk.

What This Means in Practice

If dependency trust can no longer be assumed, then controlling how software is built becomes critical.

This is where approaches that focus on verified inputs and reproducible builds start to matter. Instead of pulling dependencies directly from public registries at build time, systems can be constructed from curated, trusted sources with full visibility into what is included.

The goal is not to eliminate open source, but to ensure that what enters the system is known, controlled, and verifiable.

This is the direction many modern build systems are moving toward, including approaches like CleanStart that focus on verifiable, reproducible software foundations.

Closing Thought

Security conversations often focus on what happens after deployment.

But these incidents reinforce a different reality.

By the time the application runs, the outcome may already be decided.

The integrity of a system is determined not just by how it behaves, but by what it was built from.

And increasingly, what it is built from cannot be taken at face value.