Look for release jobs that can be triggered by low-trust actors, jobs that checkout pull request heads, and jobs that combine install, test, and publish steps in one identity context. If the same workflow can both consume unreviewed code and mint a trusted registry identity, the trust boundary is too wide and should be split.
How to tell when trusted publishing has crossed the line
trusted publishing is meant to narrow the gap between build-time trust and release-time authority. It becomes too permissive when one workflow can accept unreviewed code, run with the same identity that is allowed to publish, and expose that path to actors or events that should not control release. The practical question is whether the publishing boundary is still isolated from code intake.
Where permissiveness shows up in the workflow design
The clearest sign is CI/CD Pipeline Identity Security Guide style overreach: a single pipeline identity can do too much if it both evaluates code and performs release actions. That usually means the workflow is not just authenticating to the registry, but also acting as a privileged control plane for the entire release path.
Another warning is when build logic depends on pull request state or untrusted forks while still retaining publish rights. The danger is not only malicious code execution, but also accidental expansion of who can influence the release identity through branch logic, reusable workflows, or permissive event triggers. If a release job is reachable from low-trust inputs, trust has leaked upstream.
Release jobs should also be examined for blast radius. Ultralytics PyPI compromise 2024 shows the classic failure mode: a workflow or token that is fine for one task becomes dangerous when it can both process code and publish artifacts. The issue is not whether the publish step is present, but whether the same identity context can reach it from an untrusted execution path.
What separates acceptable automation from excessive trust
A safe publishing design keeps code review, test execution, and registry minting in different trust zones. Low-trust steps can run early and often, but they should not inherit the ability to mint or reuse the final publishing identity. The more a workflow depends on environment state, mutable refs, or hidden job inheritance, the less trustworthy the release boundary becomes.
Teams should treat long-lived or broadly scoped publish credentials as a fallback, not as the normal path. Trusted publishing is strongest when the release identity is short-lived, tightly bound to the exact workflow, and usable only after the conditions for release are satisfied. If the same identity can be replayed across branches, repositories, or jobs, the boundary is already too loose.
The most useful test is simple: can the workflow still publish if the code it just tested was never meant to be trusted? If the answer is yes, then the publishing step is too close to unreviewed code, and the release trust model is weaker than the automation suggests.
Risk and Threat Considerations
Overly broad trusted publishing turns a delivery pipeline into a release primitive for attackers. If an untrusted pull request, compromised maintainer path, or poisoned reusable workflow can reach the publish identity, an adversary can turn code execution into package distribution, dependency poisoning, or credential exposure.
Failure mechanism: The workflow collapses code execution and release authority into one identity context, so control of the build path becomes control of the publishing path. That allows an attacker or low-trust contributor to trigger a job that both consumes unreviewed code and mints a trusted artifact identity.
Impact: A single weak trust boundary can produce signed or otherwise trusted malicious releases, broader supply-chain propagation, token exposure, and loss of confidence in the registry identity used for legitimate publishing.
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 and OWASP API Security Top 10 address the attack and risk surface, while SLSA 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-05 — Overprivileged NHI | Trusted publishing becomes risky when one workflow identity can both build and publish. |
| NHI-07 — Long-Lived Secrets | Permissive publishing often persists through reusable or reusable release credentials. | |
| Recommendation — Split publish authority from build execution and remove unnecessary release privileges. Replace durable publishing secrets with tightly bound short-lived release credentials. | ||
| SLSA | Build provenance | Trusted publishing is strongest when artifact provenance is bound to the exact release workflow. |
| Recommendation — Bind release authority to provenance-verifiable workflows and preserve build attestation evidence. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Workflow and registry settings determine whether release authority is overly broad. |
| Recommendation — Harden CI/CD and registry settings so only approved release paths can publish. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Trusted publishing fails when the publishing identity can be invoked by untrusted paths. |
| Recommendation — Restrict authentication to the exact publishing workflow and block unauthorized trigger paths. | ||
Practitioner Guidance
What to verify: Confirm that only the final, release-approved job can mint the trusted publishing identity, and that earlier jobs cannot inherit that authority through shared environment, reusable workflow, or branch-trigger logic.
Common mistake: Teams often secure the token issuance mechanism but leave the workflow topology untouched. If the release job still accepts code from untrusted heads or fork-driven paths, the trust model remains too broad even if the credential itself is short-lived.
What good looks like: The build can fail, test, or be rerun many times without ever creating a path to publish unless the exact release conditions are met. Code intake and artifact publication should be separate enough that compromise of one does not automatically grant the other.
Practitioner takeaway: Trusted publishing is permissive only when the release identity is reachable from the same path that ingests unreviewed code. If one workflow can both evaluate and publish, split the trust boundary before you rely on the control.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org