Provenance Is Not a Security Verdict: What npm Trusted Publishing Actually Protects

A package shows a provenance check. The build came from GitHub Actions. Publishing used OIDC rather than a long-lived npm token. That sounds like: safe.

That conclusion goes too far.

In 2026, npm expanded Trusted Publishing. Packages can be published from supported CI/CD systems using OpenID Connect without keeping a long-lived write token in the workflow. Public packages built from public GitHub or GitLab repositories can also receive provenance automatically. That is a meaningful supply-chain improvement.

But provenance primarily answers an origin question: Which workflow, repository, and commit produced this artifact? It does not automatically answer: Was the source code benign, were all dependencies trustworthy, and was the workflow itself secure?

That distinction belongs in every serious dependency and CI review.

What Trusted Publishing improves

Traditional npm automation often uses a secret such as NPM_TOKEN. The token lives in CI and remains valid until it expires or is revoked. If it is printed into logs, read by a compromised workflow, or never rotated, a reusable publish route remains open.

Trusted Publishing changes the model. npm establishes trust with a specific CI/CD workflow. The workflow receives short-lived, signed identity claims through OIDC and uses them for the publish operation. There is no long-lived publish secret for somebody to copy and reuse later.

That removes an entire class of persistent credentials from the release path.

Provenance is a receipt, not a quality seal

npm provenance can show the source repository, source commit, workflow, and build environment. GitHub Artifact Attestations similarly bind artifacts to information about repository, workflow, commit, trigger, and build environment.

That matters because origin and integrity become easier to verify. But the attestation does not say that the commit contains no malicious code, that the workflow uses no dangerous third-party action, that a maintainer account was not compromised, or that the tests are meaningful.

GitHub explicitly warns that attestations are not a guarantee that an artifact is secure. They provide information that consumers must evaluate against their own policy.

Provenance makes trust more verifiable. It does not replace the decision about what and whom you trust.

Example: perfectly attested malicious code

Imagine an npm package. A maintainer deliberately adds code that sends environment variables to an external server at startup. The commit is merged normally. GitHub Actions builds exactly that commit. Trusted Publishing authenticates exactly that workflow. npm creates correct provenance.

The chain can be cryptographically consistent — and the package can still be malicious.

The attestation proves that you received the artifact produced by that workflow from that commit. It does not prove that the commit should have been released.

Five red flags in the release path

1. Legacy publish tokens still exist

Trusted Publishing is configured, but the old automation token remains in repository secrets. Two publishing paths now exist. npm recommends verifying the migration, then restricting traditional token access and revoking automation tokens that are no longer required.

Check which npm tokens remain, which can write, and whether old CI systems or local release scripts can still publish.

2. The publisher is trusted, but the workflow is not

OIDC binds publishing to a workflow, making that workflow a high-value security boundary.

GitHub recommends pinning actions to a full-length commit SHA when immutability matters. Tags and branches can move. Release workflows should also use minimal permissions, keep untrusted pull-request contexts away from publishing, and protect changes to workflow files.

Trusted Publishing secures authentication to npm. It does not automatically secure every action and shell step that leads to it.

3. Nobody inspects the actual publish artifact

A source repository and npm tarball are not necessarily identical. Build steps generate files, bundlers replace values, and publish scripts can include additional content. Internal source maps, fixtures, local configuration, or even secrets can end up in a package.

Before npm publish, inspect what will actually ship. What does npm pack --dry-run show? Which files enter the tarball? Do files, .npmignore, and build output agree? Are source maps intentionally public?

4. Provenance is displayed but never verified

A registry indicator is useful, but critical dependencies deserve more than a visual check. npm documents npm audit signatures for verifying registry signatures and available provenance attestations.

Missing provenance does not automatically make a package unsafe. Existing provenance does not automatically make it safe. The value is additional verifiable context.

5. Dependabot is treated as security approval

Automated updates reduce stale versions and expose fixes faster. A green bot PR still does not explain why a dependency is needed, whether new lifecycle scripts or transitive packages were introduced, whether ownership changed, or whether the package now accesses the network, filesystem, or build secrets.

Automation proposes a change. Review evaluates the risk.

A practical supply-chain review

A useful audit follows the entire path to production:

• Release identity: OIDC versus long-lived tokens, publisher binding, legacy publish paths, 2FA, and maintainers.
• Workflow integrity: pinned actions, minimal permissions, protected tags and branches, and no untrusted inputs in the release path.
• Artifact contents: inspect the tarball or build output before release and exclude secrets or internal files.
• Provenance: generate and technically verify attestations; compare repository, commit, and workflow with expectations.
• Dependency governance: review new packages more heavily than routine updates, use dependency review, remove unused packages, and consciously restrict automatic paths to production.

What Website-Pflichtencheck would inspect

For websites and SaaS products, supply-chain security does not stop at the server. A technical review can examine npm, pnpm, or yarn dependencies, lockfile consistency, CI/CD permissions, GitHub Action pinning, secret and token use, OIDC/Trusted Publishing, build artifacts, provenance, dependency review, and protection of critical releases.

The goal is not to treat every dependency as a crime scene. The goal is to know exactly which steps exist between “someone changed code” and “this code now runs on the website.”

Provenance is the receipt showing where software came from. It is not the certification that running it is safe.