Stop Eating Hamburgers Off the Sidewalk: Securing the npm Supply Chain

TLDR: The npm ecosystem has long suffered from an implicit trust gap where developers pull code without verifying its origin. By implementing build provenance using Sigstore, maintainers can now cryptographically link packages to their specific source commits and build instructions. This shift moves the industry away from fragile, human-centric signing methods like PGP toward verifiable, machine-identity-based trust that makes supply chain attacks significantly harder to hide.

Software supply chain security is currently a mess of "trust me, bro" dynamics. When you run npm install, you are essentially picking up a burger off the sidewalk and eating it because it looks like it came from a reputable kitchen. You have no idea if it was dropped, tampered with, or cooked by someone who shouldn't be in the kitchen at all. We have seen this play out repeatedly with high-profile compromises like CVE-2022-23648 in node-ipc and the account hijacking of ua-parser-js. These attacks succeed because the registry of record—npm—has no ironclad, verifiable link back to the source code repository where the project actually lives.

The Gap of Implicit Trust

The fundamental problem is that source repositories and package registries are disconnected. A developer pushes code to GitHub, a CI/CD pipeline builds it, and then someone (or something) uploads the resulting artifact to npm. There is no cryptographic proof that the code you are installing is the same code that was reviewed in the pull request. We have been relying on PGP signatures for years, but let’s be honest: PGP is a usability nightmare. It requires managing durable private keys, which are easily lost, stolen, or mismanaged. When a maintainer’s laptop is compromised, their PGP key is compromised, and the entire chain of trust evaporates.

Bridging the Gap with Provenance

The research presented at Black Hat 2023 highlights a shift toward using Sigstore to provide non-falsifiable build provenance. Instead of relying on long-lived PGP keys, this approach uses short-lived, ephemeral keys managed by Fulcio and a public transparency log called Rekor.

When a package is published with the --provenance flag, the build system requests a signed OIDC token. This token acts as a machine identity. The build is signed, the signature is sent to the transparency log, and the private key is discarded. This eliminates the need for maintainers to manage sensitive key material. For a pentester or researcher, this is a game-changer. You no longer have to guess if a package is legitimate; you can query the transparency log to see exactly which CI/CD pipeline produced the artifact and which commit it corresponds to.

To start using this, maintainers update their GitHub Actions workflow:

- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

This command triggers the generation of an attestation that links the package to the specific build environment and source commit. It doesn't make the code inherently secure—a malicious maintainer can still write malicious code—but it makes the process transparent. If an account is hijacked, the attacker cannot easily forge this provenance without access to the legitimate CI/CD environment, which is a much higher bar to clear than simply stealing a PGP key.

Why This Matters for Pentesters

During an engagement, your goal is often to identify the weakest link in the target's infrastructure. If you are performing a supply chain assessment, you should be looking for packages that lack this provenance. If a package is published without it, you are dealing with the old, insecure model. You can now use the npm audit command to check for these signatures.

The OWASP Top 10 has long warned about using components with known vulnerabilities, but the real danger is the unknown vulnerability injected via a compromised maintainer account. By verifying provenance, you can quickly filter out dependencies that haven't adopted these modern security practices. It allows you to focus your efforts on the parts of the dependency tree that are most likely to be vulnerable to injection or tampering.

Moving Toward Machine Identity

The industry needs to stop pretending that human-managed PGP keys are a viable security strategy for open source. We are moving toward a world where machine identity is the standard. This isn't just about npm; it is about creating a verifiable paper trail for every piece of software we consume.

If you are a researcher, start auditing the transparency logs. If you are a developer, start demanding provenance from your dependencies. The tools are there, and the SLSA framework provides the roadmap for where we need to go. We are finally building a system where we can actually verify what we are running, rather than just hoping the maintainer had a secure laptop. Stop accepting the status quo of implicit trust and start verifying the provenance of the code you ship.