The release pipeline becomes an attacker-controlled publishing path. If push access can invoke package publication, the attacker no longer needs to steal registry tokens or compromise the package manager. The practical failure is that trusted automation authenticates the workflow, not the intent of the commit that started it.
Why This Matters for Security Teams
When a push credential can trigger release automation, code review and repository trust are no longer enough. The workflow becomes part of the attack path, which means a compromised developer token can turn into an unauthorised publication event, secret exposure, or malicious package release. That is why NHI governance has to cover CI/CD identities, not just human accounts, as reflected in CI/CD pipeline exploitation case study and the OWASP Non-Human Identity Top 10.
Security teams often assume a protected branch or required review is enough, but release orchestration usually depends on credentialed automation that trusts the event, not the intent behind it. Once that trust boundary is crossed, an attacker can publish artifact versions, change dependencies, or exfiltrate signing material through the pipeline itself. NHI Management Group research on the Guide to the Secret Sprawl Challenge shows how frequently secrets and automation paths are coupled in ways teams underestimate. In practice, many security teams encounter pipeline abuse only after a malicious release has already been accepted as legitimate automation.
How It Works in Practice
The core failure is that push access and publish authority become the same thing. If a compromised push credential can open a pull request, merge to a release branch, or directly invoke a release job, the attacker inherits the workflow’s trust. That can mean package publication, container image build-and-push, artifact signing, or deployment to a downstream environment. In modern CI/CD systems, this is not limited to one toolchain. The risk appears anywhere a commit event or webhook is treated as sufficient proof that the release should proceed.
Current guidance suggests separating code contribution from release authority. That usually means three controls working together:
- Use distinct identities for developer push access, build execution, and publication steps.
- Gate release jobs on signed attestations, policy checks, or approved change metadata instead of raw branch pushes.
- Issue short-lived secrets only at the moment of need, then revoke them automatically after the task completes.
This is where workload identity matters. For CI/CD, the pipeline runner or release service should authenticate as a workload, not as a human proxy. Standards-based approaches such as NIST SP 800-63 Digital Identity Guidelines and the operational patterns described in Ultimate Guide to NHIs — Static vs Dynamic Secrets support the shift from long-lived static credentials to ephemeral access. The practical point is to authenticate the pipeline step that is authorized to publish, not the commit that merely triggered the job. These controls tend to break down in monolithic release chains where build, test, sign, and publish all run under one shared token because compromise of any step becomes compromise of the entire release path.
Common Variations and Edge Cases
Tighter release controls often increase delivery friction, so organisations have to balance speed against blast-radius reduction. That tradeoff becomes more visible in high-velocity repositories, emergency hotfix flows, and open-source maintainership where release automation is intentionally broad. Best practice is evolving, and there is no universal standard for this yet, but the direction is clear: trust should be scoped to the smallest publishable unit, not the broadest contributor identity.
Edge cases matter. A commit signed by a trusted developer is still unsafe if the developer token was phished or stolen. A protected branch is still vulnerable if a compromised push credential can alter the workflow file that defines publication behaviour. And a release pipeline that reuses the same secret across build and publish stages can be subverted even when the source code itself looks clean. The attack pattern is especially dangerous in environments with self-hosted runners, shared service accounts, or manual approval gates that do not verify artifact provenance. NHI Management Group’s 52 NHI Breaches Analysis and the Reviewdog GitHub Action supply chain attack both illustrate how quickly trusted automation can be turned into a distribution channel once identity boundaries are too loose.
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 | Covers overprivileged and long-lived non-human credentials in release automation. |
| OWASP Agentic AI Top 10 | A-04 | Agentic workflow trust is similar to CI/CD automation that acts on events, not intent. |
| CSA MAESTRO | M-2 | Addresses identity and trust boundaries for autonomous workflow execution. |
| NIST AI RMF | Applies governance, accountability, and risk treatment to autonomous release behaviour. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when push credentials can trigger publishing. |
Bind release authority to verified workload identity and isolate publish privileges from code push rights.
Related resources from NHI Mgmt Group
- What breaks when an npm maintainer identity is compromised in a CI/CD pipeline?
- What breaks when CI/CD workflow actions or build credentials are tampered with?
- What breaks when AI agents are allowed to act inside privileged CI/CD workflows?
- What breaks when CI/CD workflows can run untrusted code with privileged tokens?
