Hardcoded secrets break rotation, ownership, and offboarding at the same time. They become embedded in repositories, build systems, and configuration files, which means the credential can survive long after the workflow changes. That creates hidden persistence and makes remediation dependent on finding every copy first.
Why This Matters for Security Teams
hardcoded secret do more than violate hygiene; they collapse the separation between code, identity, and access control. Once a token is embedded in a pipeline, the pipeline becomes an identity holder, not just an execution path. That undermines rotation, revocation, and offboarding because every copy has to be found before the credential can truly be removed. GitGuardian’s The State of Secrets Sprawl 2026 found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why detection without revocation is not enough.
The practical risk is exposure across build logs, runner environments, repo history, config files, and downstream artefacts. Security teams often assume private repos or internal pipelines are safer, but the attack surface is broader than source control alone. That is why current guidance from the OWASP Non-Human Identity Top 10 treats non-human credentials as identities that need lifecycle control, not static configuration values. The same pattern shows up in CI/CD pipeline exploitation case study and the Guide to the Secret Sprawl Challenge, where persistence and propagation matter more than the original leak point. In practice, many security teams encounter credential abuse only after the pipeline has already promoted the secret into multiple systems, rather than through intentional access design.
How It Works in Practice
The control objective is to stop pipelines from holding durable secrets at all. Instead of placing API keys or certificates in repository variables, build definitions, or image layers, teams should issue short-lived credentials at runtime and bind them to the workload identity that is executing the job. That is the operational direction behind Zero Trust and identity-first design in the OWASP Non-Human Identity Top 10, and it fits naturally with the compromise patterns described in the CI/CD pipeline exploitation case study.
A workable pipeline model usually includes:
- Workload identity for the runner or job, so the system authenticates what is executing before issuing access.
- JIT credential provisioning, so the secret exists only for the task window and is revoked automatically on completion.
- Policy evaluation at request time, so access can be constrained by environment, branch, artifact, or deployment target.
- Separation of secret source from pipeline logic, so build steps never need to know the long-lived value.
- Automated scanning and revocation, because discovery alone does not remove a credential from downstream copies.
This matters most for CI/CD runners, ephemeral containers, and supply chain tooling where one job can fan out into many systems quickly. NHIMG’s research on the Reviewdog GitHub Action supply chain attack shows how third-party automation can multiply the blast radius of a single exposure. These controls tend to break down when legacy deployment scripts require persistent environment variables because the pipeline was built around convenience, not identity-aware issuance.
Common Variations and Edge Cases
Tighter secret controls often increase build complexity and operational overhead, so organisations have to balance reduced exposure against pipeline reliability and developer velocity. Best practice is evolving, especially where release systems, infrastructure-as-code, and third-party actions all expect credentials to be present by default.
One common exception is third-party tooling that cannot mint its own short-lived credentials. In that case, teams sometimes use a broker or vault to exchange a runner identity for a scoped token, but that only works if the exchange itself is strongly bound to workload identity and expiry. Another edge case is artefact signing or package publishing, where some components may still need a durable root of trust; even there, the signing authority should stay isolated from the pipeline rather than sitting in plain text variables.
The same caution applies to secret scanning tools. They are valuable, but they do not solve ownership. If a credential appears in a build log, a cache, or a copied template, the secret can keep living long after the original repository is fixed. For that reason, NHIMG’s Shai Hulud npm malware campaign analysis is useful reading for understanding how package and pipeline trust chains overlap. The same lesson appears in the 52 NHI Breaches Analysis: secret leakage becomes an identity governance problem as soon as the credential is reusable outside the job that exposed it.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses non-human credential lifecycle and rotation failures. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is required when pipelines act as identities. |
| NIST AI RMF | Accountability for autonomous tool use applies when pipelines self-act on secrets. |
Replace hardcoded pipeline secrets with short-lived NHI credentials and automate rotation and revocation.
