They often assume provenance replaces older authentication paths automatically. It does not. If a legacy token, secret, or key remains valid, the attacker can use that path even when provenance controls exist. The control failure is leaving old and new trust models active at the same time.
Why This Matters for Security Teams
Package provenance and trusted publishing are often treated as a clean replacement for older software release controls, but the real risk is overlap. A signed build or verified publisher can improve integrity, yet it does not invalidate a still-active API token, CI secret, or maintainer key. The attacker only needs one surviving path. NIST SP 800-53 Rev 5 Security and Privacy Controls makes this point indirectly through strong access control, revocation, and system integrity requirements, which is why provenance should be treated as an additional trust signal, not a universal kill switch.
This matters because release pipelines, package registries, and developer identities are all part of the same trust chain. If old credentials remain valid after trusted publishing is introduced, security teams may believe the package is protected when the legacy path is still exploitable. NHIMG research on the LiteLLM PyPI package breach shows how package ecosystems can be undermined when credential exposure and publishing trust are not managed together. In practice, many teams discover this only after a compromised token is used to bypass the new provenance workflow.
How It Works in Practice
Trusted publishing shifts release trust away from long-lived secrets and toward a short-lived, identity-backed assertion from the build environment. In principle, that is a major improvement: the package is published by a verified workload, not by a static token copied into a pipeline variable. In practice, the control only holds if older paths are removed or tightly constrained.
A robust implementation usually combines three layers:
- Trusted publishing or signed provenance for the release event itself.
- Revocation of legacy API tokens, passwords, and maintainer keys that used to publish the same package.
- Verification and monitoring that no alternate path still has write access to the registry or repository.
That is why organisations often map these controls to broader software supply chain guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls and package integrity practices in the Ultimate Guide to Non-Human Identities. The operational issue is not proving that a build was legitimate once, but proving that only the legitimate path can still publish now. Modern controls should therefore include secret inventory, rotation, and offboarding for package-maintainer identities, especially where CI/CD systems can still sign in with older credentials.
Best practice is evolving toward policy that blocks dual trust paths by default: if trusted publishing is enabled, legacy credentials should be disabled or restricted to break-glass use with explicit approval. These controls tend to break down in large estates where multiple automation systems, forked repositories, and inherited maintainer tokens still have hidden write access.
Common Variations and Edge Cases
Tighter provenance enforcement often increases operational overhead, requiring organisations to balance release speed against the cost of migration and cleanup. That tradeoff becomes visible in older ecosystems where maintainers publish from local machines, automation jobs, and mirrored CI systems at the same time.
There is no universal standard for this yet, but current guidance suggests treating trusted publishing as part of a phased trust migration rather than a flip-the-switch control. Edge cases include packages that must support emergency hotfixes, projects with external maintainers, and organisations using multiple registries with different authentication models. In those environments, provenance can be technically correct while still leaving a parallel path open.
The most common failure modes are:
- Leaving a legacy token active after switching to trusted publishing.
- Assuming registry-side verification blocks repository-side compromise.
- Ignoring maintainer and CI secrets that can still publish or overwrite artifacts.
NHIMG analysis of the Ultimate Guide to Non-Human Identities shows why this matters across the identity lifecycle: 71% of NHIs are not rotated on time, and only 20% have formal offboarding and revocation processes. That is the same pattern here. Provenance does not compensate for weak revocation hygiene, and security teams that miss this usually discover the gap when an old credential is used after the new trust model is already live.
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 Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses credential rotation and removal of legacy publishing secrets. |
| OWASP Agentic AI Top 10 | A-06 | Covers tool and credential abuse when automation still has active access paths. |
| CSA MAESTRO | IDM-02 | Supports workload identity and lifecycle controls for non-human release systems. |
| NIST AI RMF | Applies governance and lifecycle risk management to automated release trust decisions. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to eliminating parallel publishing paths. |
Treat build and release automation as active identities and revoke unused access paths.
