Use separate identities for build, sign, and deploy, and make credential scope as narrow as the task allows. Governance should cover what can execute, what can authenticate, and what can be reused after execution. If a workflow can both run untrusted code and reach production, the control boundary is too loose.
How to structure governance across build, sign, and deploy
CI/CD supply chain risk becomes manageable when teams treat build, signing, and deployment as separate trust steps rather than one blended workflow. The practical governance question is not just who can trigger automation, but which identity can create artifacts, which identity can attest or sign them, and which identity can move them into production. That separation limits blast radius and makes compromise easier to contain.
A useful way to think about this is that each stage should have its own purpose-built identity, permissions, and approval boundary. Build systems should compile and test, signing systems should attest to artifact integrity, and deployment systems should promote only already-approved outputs. When those roles collapse into one token or one broadly privileged pipeline, the workflow can turn from a delivery mechanism into a lateral-movement path.
Governance also needs to account for post-execution reuse. If a job can read long-lived secrets, reuse cloud credentials, or inherit ambient permissions after the task finishes, the control boundary is too loose even if the pipeline itself looks successful. The right question is whether the pipeline can still do meaningful damage after the intended action is complete.
What strong supply chain governance should control
Strong governance starts by deciding what a pipeline is allowed to execute, what it is allowed to authenticate as, and what it is allowed to pass forward. That means limiting token scope, avoiding shared credentials across repositories or environments, and preventing untrusted code from reaching secrets, signing material, or deployment paths. It also means treating third-party actions, packages, and reusable workflow components as dependencies that require review and version pinning.
Teams should also separate provenance from privilege. An artifact can be verifiably built and still be unsafe to deploy if the build job had too much access or if a reusable action could mutate the release path. Supply chain governance is strongest when provenance, identity, and authorization are all constrained together rather than handled as isolated controls. For practical guidance on that model, see CI/CD Pipeline Identity Security Guide.
In CI/CD environments, this usually means making short-lived, narrowly scoped credentials the default and using explicit trust rules for each stage. A build job should not automatically inherit deploy rights, and a signing job should not share the same identity as a pull-request runner. If a workflow can execute untrusted code, it should be isolated from the identities that protect release integrity. That principle is central to the supply-chain cases documented in CI/CD pipeline exploitation case study and ArtiPACKED 2024.
Why CI/CD supply chain failures become security incidents
CI/CD pipelines are attractive targets because they often concentrate secrets, release privileges, and trust relationships in one automated path. A single compromised maintainer token, action, or artifact can expose production credentials, alter build outputs, or silently publish malicious code. That is why supply chain risk in delivery systems is usually less about one broken control and more about an unsafe combination of trust, reuse, and reach.
The main failure mode is privilege concentration. When the same workflow can both run arbitrary code and access signing keys or deployment credentials, attackers only need one foothold to turn a development compromise into a production compromise. Coverage of this pattern in incidents such as reviewdog Action compromise 2025, tj-actions/changed-files compromise 2025, and CircleCI breach 2023 shows how quickly secrets exposure can cascade once pipeline trust is overextended.
Build provenance also matters because downstream consumers need to know not only what was produced, but under what authority it was produced. Modern supply chain controls work best when the signing step is isolated, the signing key or token is tightly protected, and deployment trusts only the signed result rather than the build environment itself. That is the practical reason many teams pair delivery governance with SLSA and NIST SSDF (SP 800-218).
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 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance is central to CI/CD supply-chain governance. |
| Recommendation — Require provenance and integrity checks before trusting produced artifacts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CI/CD governance depends on scoped, short-lived credentials and token lifecycle control. |
| IA-9 — Service Identification and Authentication | Build, sign, and deploy identities in CI/CD are machine or service identities. | |
| AC-6 — Least Privilege | The question is about limiting what pipeline identities can execute and access. | |
| Recommendation — Manage pipeline credentials with tight issuance, rotation, and revocation rules. Authenticate each pipeline stage with a distinct service identity and no shared access. Constrain each pipeline step to the minimum privileges needed for its task. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | CI/CD service identities become risky when they can both run code and reach production. |
| Recommendation — Audit pipeline identities for excess permissions and split unsafe trust boundaries. | ||
Practitioner Guidance
What to prioritise: Start with the credentials and identities that can cross trust boundaries, especially anything that can read secrets, publish artifacts, sign releases, or deploy to production. Those are the controls that define the real blast radius.
What to verify: Confirm that build, sign, and deploy use separate identities, separate approval paths, and separate secret scopes. If a single workflow token can touch both untrusted code and production, treat that as a design defect rather than a tuning issue.
Decision rule: If a pipeline step can execute third-party or pull-request code, do not allow it to reuse credentials that can authenticate outside that step. If the step needs more privilege than the task itself requires, split the job or move the sensitive action into a tighter trust zone.
What good looks like: A successful pipeline leaves behind a narrow, auditable identity trail, with short-lived credentials, pinned dependencies, isolated signing, and deployment rights that cannot be inherited by routine build execution. The best governance outcome is not zero risk, but a sharply reduced path from code execution to production control.
Practitioner takeaway: Governance should follow the trust boundary, not the pipeline convenience, because CI/CD risk is usually created by credentials that outlive the step that needed them.
Related resources from NHI Mgmt Group
- How should security teams govern software supply chain risk when CI/CD identities can publish code?
- How should security teams implement dependency mapping in CI/CD pipelines to reduce supply chain risk?
- How should security teams implement checksum validation in CI/CD pipelines to reduce supply chain risk?
- How should security teams handle a mobile supply-chain compromise in development and CI/CD environments?