How should organisations govern CI/CD and NHI access in application delivery?

How CI/CD identities should be governed as part of application delivery

CI/CD access is not just a build-system concern, it is application-delivery authority. When a pipeline can sign artefacts, publish packages, deploy to production, or read secrets, the identity behind that pipeline needs clear ownership, scoped permissions, and a defined lifecycle. The governance question is whether the pipeline can act only where intended, for only as long as intended, and with evidence that those powers are still justified.

A practical governance model treats each pipeline identity like any other privileged application actor: it should have an owner, a bounded purpose, and a reviewable permission set. That includes service accounts, bot users, federated workload identities, and automation tokens used by build and release tooling. The governance boundary matters because a compromise or stale grant in the delivery path can change code, packages, or deployment targets faster than a human reviewer can intervene.

That means access decisions should be tied to delivery functions, not to team convenience. For example, a pipeline that builds artefacts should not automatically be able to deploy them, and a release job should not retain standing access to every environment. Where possible, use short-lived credentials, environment-specific authorization, and explicit approval steps for actions that cross a trust boundary, especially when the pipeline can touch secrets or production infrastructure. CI/CD Pipeline Identity Security Guide is useful here because it focuses on the identity controls that make delivery paths safer without weakening automation.

What should be governed across CI/CD and NHI access

The main control layers are permission scope, credential lifetime, and lifecycle management. Scope defines what the identity can do, lifetime defines how long it can do it, and lifecycle defines what happens when the pipeline, repository, environment, or owning team changes. If any one of those is vague, the organisation is effectively leaving production change authority to an account that no one fully owns.

Offboarding deserves the same discipline as onboarding. When a repository is retired, a pipeline renamed, a service account replaced, or a deployment path decommissioned, the associated identities and tokens should be reviewed, disabled, or deleted rather than left to linger. This is especially important for secrets embedded in older jobs, inherited credentials in shared runners, and automation tokens that were granted for a temporary project but never removed. Service Account Security Guide and NHI Ownership and Accountability Guide both support that lifecycle view by tying access to a named owner and a cleanup path.

Governance also needs to cover how delivery identities are created. Federated, keyless patterns reduce the need for static secrets, but they do not remove the need for trust policy, claim validation, and environment separation. The point is not to eliminate automation, it is to make each automated actor auditable, revocable, and narrowly trusted. For broader non-human identity coverage, Ultimate Guide to NHIs provides the parent model for ownership, rotation, and offboarding.

What good governance looks like in practice

Good practice starts with inventory. Organisations should be able to list every CI/CD identity, what system created it, what it can access, which secrets or tokens it uses, and who is responsible for approving changes. Without that inventory, rotation becomes guesswork and offboarding becomes incomplete.

• Map each pipeline identity to an owner and a business purpose.
• Separate build, test, sign, and deploy permissions instead of reusing one powerful token everywhere.
• Prefer short-lived federation or managed identity patterns over long-lived shared secrets.
• Review access when code ownership, environments, or delivery tooling changes.
• Log and alert on credential creation, privilege expansion, and unexpected deployment actions.

Governance is strongest when delivery access is periodically recertified by the team that owns the application, not only by the platform team that runs the tooling. That keeps the control aligned to the real risk: the pipeline is part of the application surface, so its access should be judged like any other application privilege. The same logic underpins Top 10 NHI Issues, which is useful for understanding where NHI programmes usually fail in practice.

Risk and Threat Considerations

CI/CD identities are attractive to attackers because they often have broad, repeatable access and are trusted by other systems. If a token, service account, or federated trust is overprivileged, an attacker does not need to break the application itself, they can alter the delivery path, inject malicious code, or harvest secrets from build and release steps.

Failure mechanism: Standing credentials, weak trust policies, or orphaned pipeline identities let a compromised job, repository, or maintainer session pivot into build tampering, secret exposure, or unauthorized deployment.

Impact: The result can be poisoned artefacts, compromised production releases, lateral movement into adjacent systems, and loss of confidence in the software supply chain.

Practitioner Guidance

What to prioritise: Start with the pipeline identities that can deploy, sign, publish, or read production secrets. Those are the accounts where excess privilege creates immediate blast radius, so they deserve the first permission review and the fastest rotation path.

What to verify: Confirm that every delivery identity has a named owner, a narrow purpose, and an expiry or review point. If the team cannot explain why the identity still exists, treat it as a deprovisioning candidate rather than a dormant asset.

Common mistake: Teams often secure the runner or the repository but leave the automation token untouched. That misses the real control point, because the identity and its trust policy are what determine whether the pipeline can still act after the underlying system looks healthy.

Practitioner takeaway: The safest delivery model is not the one with the fewest automated identities, it is the one where every automated identity has bounded authority, visible ownership, and a clean removal path when its job is finished.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• What is the difference between role-based access and API key governance for NHI security?
• How do organisations operationalise NHI ownership at scale?