A CI/CD secret is a credential used by build or deployment automation to reach source control, cloud services, registries, or internal systems. In practice it is a non-human identity artifact, so its scope, lifetime, storage location, and revocation path must be governed like any other privileged access token.
Expanded Definition
CI/CD secrets are not just “build credentials.” They are privileged NHI artifacts that let automation authenticate to Git hosts, artifact registries, cloud APIs, signing services, and internal deployment targets. In mature environments, a CI/CD secret may be short-lived, brokered through federation, or minted on demand; in weaker setups it is a long-lived static token stored in variables, runner images, or pipeline logs. The operational difference matters because the same secret can be harmless in a narrow, ephemeral job and catastrophic if it survives beyond the job boundary.
Definitions vary across vendors, but NHI Management Group treats CI/CD secrets as part of the broader secrets lifecycle, not as a separate convenience token class. That means scope, storage, rotation, and revocation must be governed with the same discipline as other machine identities, and mapped to controls such as the OWASP Non-Human Identity Top 10. The most common misapplication is treating a deployment token as “safe because it is only for automation,” which occurs when the same credential is reused across branches, environments, or long-lived runners.
Examples and Use Cases
Implementing CI/CD secrets rigorously often introduces release friction, requiring organisations to weigh developer speed against tighter job isolation, short token lifetimes, and stronger revocation discipline.
- A GitHub Actions workflow fetches a cloud access token at job start and discards it at job end, reducing the blast radius compared with a static repository secret.
- A deployment pipeline signs container images with a dedicated signing key stored outside the runner, similar in risk posture to cases discussed in the CI/CD pipeline exploitation case study.
- A build job accesses a private package registry through a narrowly scoped token, aligned with least privilege guidance from the OWASP Non-Human Identity Top 10.
- An engineer replaces hardcoded credentials in pipeline YAML with a secrets manager integration after reviewing the patterns described in the Guide to the Secret Sprawl Challenge.
- A compromised runner is treated as a credential incident because the secret was mounted into the environment, not isolated behind a broker.
These examples show that the important question is not whether a pipeline “has a secret,” but whether the secret is bound to a single workflow, environment, and lifecycle event. Where organisations use federated identity for builds, the secret becomes a short-lived assertion rather than a reusable password.
Why It Matters in NHI Security
CI/CD secrets are a high-value target because they often sit at the intersection of source code, build infrastructure, and production access. Once exposed, they can be used to poison packages, alter deployment artifacts, or pivot into cloud environments. NHI Management Group research shows the scale of the problem is still rising: The State of Secrets Sprawl 2026 found 64% of valid secrets leaked in 2022 remain valid and exploitable today, proving that detection without automated revocation is incomplete defense. That is why secret handling must align with identity governance, not just DevOps convenience.
This matters especially when a pipeline is trusted more than the workstation of the engineer who triggered it. The most damaging failures often involve runner compromise, overbroad permissions, or secrets that outlive the job they were created for. In practice, CI/CD secrets should be treated as revocable operational identities with explicit ownership, monitoring, and expiry. Organisations typically encounter the need to tighten CI/CD secrets only after a leak, failed deployment, or supply chain incident, at which point the term becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses improper secret management and lifecycle control for machine identities. |
| NIST CSF 2.0 | PR.AC-1 | Supports identity and credential governance for automated access paths. |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero Trust requires strong authentication and limited trust for non-human access paths. |
Inventory CI/CD secrets, restrict scope, and enforce rotation, revocation, and storage controls.
