The control that breaks is the assumption that provenance alone guarantees safety. If an attacker can steal the workflow credentials that mint release permissions, they can create valid-looking malicious packages at scale. Practitioners should govern CI release rights as machine identities with strict scope, expiry and revocation, not as background automation.
What breaks when trusted publishing becomes a reusable launchpad?
trusted publishing is supposed to replace long-lived release secrets with short-lived, workload-issued release authority. What breaks is the safety assumption behind that model: if an attacker can capture the release workflow’s credentials or trust path, they can mint legitimate-looking packages through the same channel that was meant to increase trust. The result is not just one compromised upload, but scalable abuse of a trusted distribution mechanism.
How provenance can be valid and still unsafe
Provenance answers a narrower question than most teams assume. It can tell you that a release came from an approved workflow, but it does not guarantee the workflow was uncompromised, the inputs were benign, or the package content was safe. When release authority is delegated to automation, the integrity boundary shifts from a person’s laptop to build-time identity, runner security, and the controls around token issuance and revocation.
That is why this failure mode is especially dangerous in package ecosystems: once the attacker has access to the publishing path, the package can look structurally legitimate while carrying malicious code. The trust signal remains intact enough to pass routine consumer expectations, which is why supply-chain abuse can propagate quickly before anyone questions the artifact itself. NHIMG’s CI/CD Pipeline Identity Security Guide is useful here because it frames release tokens, OIDC federation, and signing as identity controls rather than background build plumbing.
Why package ecosystems amplify the blast radius
Package ecosystems amplify this problem because one compromised publisher can affect many downstream consumers at once. A trusted publishing compromise can produce releases that inherit normal distribution paths, automatic dependency updates, and developer confidence in registry metadata. That means the attacker does not need to win every consumer individually, only the publisher once.
In practice, the risk is broader than simple malware insertion. An abused release workflow can be used for credential theft, environment harvesting, dependency poisoning, or worm-like propagation through other maintainers’ automation. NHIMG’s Shai-Hulud npm worm first wave 2025 shows how stolen publishing tokens can turn one package compromise into a much wider secret-exposure event, while axios npm compromise 2026 illustrates how a hijacked maintainer identity can move malicious code through ordinary distribution channels.
Risk and Threat Considerations
The main risk is that trusted publishing collapses if the release identity is reused, over-scoped, or reachable from a compromised workflow. The attacker’s objective is to obtain publishing authority once, then use that authority to ship packages that blend into normal release traffic and trigger downstream consumption before defenders notice.
Failure mechanism: Release credentials, OIDC trust, or runner context are stolen or abused, allowing an attacker to mint valid release actions from an approved automation path. That turns provenance into a trust signal for malicious code instead of a barrier against it.
Impact: malicious package can be published at scale under apparently legitimate release conditions, which increases blast radius, slows detection, and can expose consumers to credential theft, dependency poisoning, or follow-on compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Trusted publishing fails when workflow auth is stolen or abused. |
| NHI-05 — Overprivileged NHI | Release workflows become dangerous when publish rights are broader than needed. | |
| NHI-07 — Long-Lived Secrets | Publishing tokens and stale workflow credentials enable republished malicious packages. | |
| Recommendation — Use short-lived, scoped release authentication and revoke compromised workflow trust immediately. Scope release identities to the minimum publish privileges and separate build from release authority. Replace durable release secrets with expiring credentials and rotate any exposed publish material. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Non-Organizational Users) | CI release workflows are non-human actors that must authenticate securely. |
| AC-6 — Least Privilege | Publishing authority should be narrowly constrained to reduce blast radius. | |
| IA-5 — Authenticator Management | Trusted publishing depends on lifecycle control of workflow credentials and tokens. | |
| Recommendation — Authenticate release automation with constrained, traceable machine identities. Limit release workflows to the minimum permissions required to publish a package. Enforce expiration, rotation, revocation, and secure handling of release authenticators. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The release path is broken when attacker-held credentials can impersonate trusted publishing. |
| API5 — Broken Function Level Authorization | Publishing authority is a privileged function that must be separately authorized. | |
| Recommendation — Harden the publishing API path against credential theft and unauthorized token use. Require explicit authorization for release actions, not just general pipeline access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Trusted publishing relies on lifecycle management of automation accounts and access paths. |
| Recommendation — Inventory, review, and disable release identities that no longer need publish access. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Attackers commonly steal build or publish credentials to abuse trusted release paths. |
| Recommendation — Monitor for exposed publishing secrets and investigate any credential discovery in build systems. | ||
Practitioner Guidance
What to verify: Treat release workflows as privileged identities. Verify who can trigger publishing, what claims the identity provider asserts, which repos or environments are trusted, and whether the workflow can mint release authority without a separate human review or scoped approval.
What changes at scale: The more packages, maintainers, and automated releases you operate, the more important expiry, revocation, and environment isolation become. Long-lived or reusable publish rights create a standing blast radius that is easy to underestimate.
Common mistake: Teams often secure the repository but leave the publishing path weak. If the release workflow can be impersonated, the package registry will usually accept the result even when the code is hostile.
Practitioner takeaway: The control objective is not just trusted release, it is bounded release authority. If a workflow can publish, then it must be governed like any other high-value identity, with least privilege, short lifetime, and fast revocation.
Related resources from NHI Mgmt Group
- Who is accountable when a release workflow publishes malicious code through trusted publishing?
- How should teams reduce risk from malicious npm package installs?
- Who is accountable when malicious code enters through a package registry?
- What breaks when malicious code can run inside a developer IDE or package install?