Because they are machine credentials that authenticate services, deployments, and software trust. If those credentials are not inventoried, scoped, rotated, and revoked like other identities, they become standing access paths inside the delivery system. Identity governance has to cover non-human authentication material, not only employee accounts.
Why CI/CD secrets and certificates belong in identity governance
CI/CD secrets and certificates are not just configuration values, they are credentials that let automated systems authenticate, sign, and deploy. Identity governance becomes necessary because these credentials create real authority inside the delivery chain. If teams treat them as “just secrets,” they often outlive the service, environment, or trust relationship they were created for.
That matters because delivery pipelines are high-trust paths. A leaked token, an overbroad certificate, or a stale signing key can impersonate a build system, a deployment robot, or a trusted integration and move code into production with legitimate-looking access.
What identity governance has to control in the delivery chain
Identity governance for CI/CD should cover the same lifecycle questions used for other identities: who owns it, what it can reach, how long it should exist, where it is stored, and how it is revoked. For this subject, the inventory must include pipeline variables, secret stores, signing certificates, OAuth client material, and any other credential that authenticates automation or software trust.
That lifecycle view is important because the risk is usually not a single bad secret, but accumulation. Long-lived credentials, copied certificates, and reusable tokens create standing access paths that are hard to see in reviews and easy to miss during offboarding or environment migration. A good governance model therefore ties each secret or certificate to a specific system, scope, expiration, and owner.
Identity governance also needs to separate authentication from authorization. A certificate or secret may prove the pipeline is trusted, but it should not automatically authorize broad access to source code, artifact registries, cloud infrastructure, or production deployment actions. The tighter the scope, the smaller the blast radius if the credential is exposed.
Why the control problem is bigger than rotation alone
Rotation helps, but it is only one part of governance. The harder problem is discovery and accountability: many CI/CD credentials are created during build automation, inherited from templates, or passed between tools without a clear owner. That makes revocation slow and increases the chance that a revoked credential still has a shadow copy in another job, runner, vault, or integration.
Certificates add another layer of trust management. They often support machine-to-machine authentication, signing, or mutual TLS, so their expiry, renewal path, and trust chain need governance just as much as passwords or API keys do. When certificates are not tracked, teams can either leave them in place too long or break deployments by revoking them without understanding downstream dependencies.
For that reason, CI/CD identity governance is as much about control boundaries as it is about hygiene. The real question is whether every automated credential has a clear business purpose, a bounded scope, and a removal path that works before an incident forces the issue.
Risk and Threat Considerations
CI/CD secrets and certificates are attractive targets because they often unlock multiple systems at once, including repositories, build runners, registries, cloud accounts, and deployment targets. Once compromised, they can support secret theft, code injection, unauthorized releases, and persistence inside the software supply chain.
Failure mechanism: A long-lived credential or signing certificate is reused across jobs, environments, or tools, then leaks through logs, artifacts, source control, or a compromised runner. The attacker can authenticate as trusted automation, extend access, and bypass normal human review.
Impact: The organisation can lose release integrity, expose downstream secrets, and ship malicious or unauthorized code under valid trust. Recovery is often disruptive because every dependent pipeline, token, and certificate chain may need reassessment at once.
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 OWASP ASVS, NIST SP 800-57 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | CI/CD secrets and certificates need revocation when jobs or trust paths end. |
| NHI-02 — Secret Leakage | The subject is specifically about secrets and certificates as exposed machine credentials. | |
| NHI-05 — Overprivileged NHI | Governance must limit what CI/CD credentials can access and deploy. | |
| Recommendation — Revoke pipeline credentials promptly when their owning service, job, or environment is retired. Scan pipelines, logs, and artifacts for exposed secrets and rotate any leaked material immediately. Scope CI/CD credentials to the minimum resources and actions each pipeline actually needs. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | CI/CD secrets and certificates are authentication material for automated services and APIs. |
| Recommendation — Harden machine authentication so leaked pipeline credentials cannot be reused broadly. | ||
| OWASP ASVS | V10 — OAuth and OIDC | CI/CD often uses OAuth clients, tokens, and certificate-bound trust relationships. |
| V11 — Cryptography | Certificates are cryptographic trust material that needs lifecycle and protection controls. | |
| Recommendation — Use strong client authentication and token handling for automation that integrates through OAuth or OIDC. Protect certificate material and verify cryptographic trust and rotation handling. | ||
| NIST SP 800-57 | Key Management | Certificate and signing-key lifecycle is central to CI/CD trust governance. |
| Recommendation — Apply formal lifecycle controls to signing keys and certificate material. | ||
| SLSA | Supply-chain Levels for Software Artifacts | CI/CD credentials protect build integrity and release trust in the software supply chain. |
| Recommendation — Strengthen build provenance and protect the credentials that authorize artifact creation and release. | ||
Practitioner Guidance
What to prioritise: Start with credentials that can authenticate to production, sign artifacts, or access other secrets. Those items deserve inventory, owner assignment, expiry, and revocation logic before lower-impact pipeline values.
What to verify: Confirm that each CI/CD secret or certificate has a named owner, a documented scope, and a tested revocation path. If you cannot show where it is used, why it exists, and how it is removed, it is not governed.
Common mistake: Teams often rotate secrets without reducing scope or eliminating reuse. That keeps the standing access path intact and leaves the same trust relationship exposed in a different form.
Practitioner takeaway: Treat delivery credentials as machine identities with lifecycle obligations, not as disposable plumbing, because the security of the pipeline depends on the same governance discipline you would apply to any other privileged access path.