Why do trusted publishing and provenance not fully protect npm packages from supply chain compromise?

Why This Matters for Security Teams

Trusted publishing improves accountability, but it does not guarantee that the build, release, or dependency chain was safe at the moment of publication. For npm, the practical risk is that provenance can authenticate a package’s path while still carrying code that was introduced through a compromised workflow, a poisoned dependency, or an abused release trigger. That is why provenance should be treated as one signal inside a broader control set, not as a stand-alone trust decision. The NIST Cybersecurity Framework 2.0 is useful here because it frames the problem as governance, protection, detection, and recovery rather than a single supply chain check.

Security teams often overestimate what a signing or provenance badge proves. It can show that a workflow identity was used, but not whether that identity had appropriate boundaries, whether the build step executed only approved code, or whether a release event was manipulated by an attacker. This becomes especially important when package publishing is automated and tightly connected to source control events, CI runners, and secrets. In practice, many security teams encounter provenance gaps only after an attacker has already turned a legitimate release path into a delivery mechanism for malicious code, rather than through intentional abuse testing.

How It Works in Practice

Provenance works best when the release process is designed so that a package can only be published by a specific, narrowly defined workflow identity, with restricted inputs and short-lived credentials. That is stronger than manual publishing, but it is still only as trustworthy as the workflow around it. If the pipeline can be influenced by unreviewed pull requests, compromised actions, mutable build scripts, or overly broad secrets access, the attestation may remain valid even though the artifact is unsafe.

In operational terms, teams should separate the duties of code review, build execution, and release authorization. They should also reduce the blast radius of release automation by using isolated runners, pinned dependencies, protected branches, and event filters that prevent untrusted changes from reaching publish steps. The core question is not just “who published this package?” but “what exactly was allowed to run before publication?”

• Restrict publish events to trusted branch or tag paths only.
• Use short-lived credentials and isolate them from general CI jobs.
• Pin build dependencies and review workflow changes with the same rigor as application code.
• Log release triggers, runner identity, and artifact hashes for later verification.

For identity-heavy release automation, the overlap with Non-Human Identity governance is direct: the workflow identity is effectively an NHI and should be treated with least privilege, rotation discipline, and explicit ownership, as reflected in the OWASP Non-Human Identity Top 10. These controls tend to break down when a single workflow token can both build and publish across multiple repositories because privilege boundaries become too broad to prevent abuse.

Common Variations and Edge Cases

Tighter provenance controls often increase release friction, requiring organisations to balance developer velocity against stronger release assurance. That tradeoff is real, especially for fast-moving open source projects where maintainers rely on automation and third-party actions to keep the release process manageable.

There is no universal standard for this yet, so best practice is evolving. Some projects use provenance as a gate for downstream consumers, while others treat it mainly as forensic evidence after publication. That difference matters because a valid provenance statement does not automatically mean the package was built from reviewed, immutable inputs. The control can be strong for attribution and still weak against workflow tampering.

Edge cases appear when releases are generated from ephemeral runners, mirrored repositories, reusable workflows, or multi-stage pipelines that split build and publish responsibility. In those environments, a small trust error in one stage can contaminate the final artifact even if the final signing step looks clean. Where agentic automation is involved, the risk expands further because autonomous tooling may approve, transform, or publish release content without clear human oversight; current guidance suggests treating those systems as privileged entities with explicit policy boundaries, not as ordinary CI helpers. The link between provenance and supply chain safety is therefore conditional, not absolute.

Related resources from NHI Mgmt Group

• What fails when package provenance is trusted too much in a supply chain compromise?
• Why do provenance attestations not fully solve supply chain compromise?
• How should security teams respond when a trusted-publisher npm supply chain compromise is detected in CI or build pipelines?
• How should security teams protect npm and package publishing workflows from identity compromise?