You lose the containment boundary. A single exposed secret can be copied into build logs, deployment tools, developer machines, and downstream environments, which makes revocation slower and incident scope much wider. Vaulting is meant to prevent exactly that replication problem by controlling where secrets can live and who can retrieve them.
Why This Matters for Security Teams
Hardcoding NHI secrets in code or CI/CD systems breaks the containment model that secrets management is supposed to enforce. Once a token, API key, or certificate lands in source control or pipeline state, it can be copied into logs, caches, artifacts, developer laptops, and downstream environments, which widens blast radius and slows revocation. NHI Management Group’s Guide to the Secret Sprawl Challenge frames this as a governance failure, not just a hygiene issue.
The operational risk is amplified because CI/CD runners and automation accounts often have broad build and deploy permissions. That makes a single leaked secret useful far beyond the original repository. Current guidance from the OWASP Non-Human Identity Top 10 treats exposed credentials as an identity problem: if the secret proves who or what the workload is, then leakage is immediate identity compromise. In practice, many security teams discover the exposure only after a build log, artifact, or runner has already replicated the secret across multiple systems.
How It Works in Practice
When secrets are stored in code, the repository becomes a distribution point. When they are stored in CI/CD systems, the pipeline becomes one. Both patterns create copies that are hard to inventory and even harder to revoke cleanly. The better model is to keep secrets in a dedicated vault, issue them just in time, and bind retrieval to workload identity and policy evaluation at request time. That means the pipeline asks for a short-lived credential only when it needs to authenticate a specific deployment action.
This is why vaulting, ephemeral credential delivery, and secret scanning must work together. Vaulting reduces where secrets can live. Secret scanning catches accidental commits. Automated rotation and revocation limit dwell time when a leak is found. The 2024 State of Secrets Management Survey reported that 88% of security professionals are concerned about secrets sprawl, which matches what response teams see during CI/CD incidents: once a secret reaches a runner or build artifact, tracing every copy becomes a manual chase.
Practically, teams should apply these controls:
- Store secrets only in a central vault, not in repos, pipeline variables, or image layers.
- Use short-lived tokens for jobs, with automatic expiry after the task completes.
- Bind secret retrieval to workload identity and environment context, not to a shared human account.
- Scan commits, manifests, logs, and artifacts before and after build steps.
- Revoke and rotate immediately when exposure is detected, then verify downstream consumers failed closed.
In the real world, this guidance breaks down when legacy pipelines depend on long-lived shared credentials and do not support workload-based retrieval because the same secret must keep working across too many stages.
Common Variations and Edge Cases
Tighter secret controls often increase build friction, requiring organisations to balance developer speed against containment and auditability. That tradeoff is especially visible in monorepos, containerized builds, and multi-tenant runner fleets, where a single credential may be tempting to reuse across many jobs. Best practice is evolving, but current guidance suggests avoiding shared static secrets even when the pipeline is “internal,” because internal repositories are not inherently safe and pipeline logs frequently outlive the job that produced them.
Edge cases matter. Some teams store secrets in CI/CD systems temporarily because a legacy application cannot yet use a vault agent or OIDC-based retrieval flow. Others rely on masked variables and assume that is enough. It usually is not, because masking does not stop exfiltration from scripts, artifacts, debug traces, or third-party actions. The CI/CD pipeline exploitation case study shows why pipeline trust boundaries need the same scrutiny as production environments. The most resilient programs pair Shai Hulud npm malware campaign lessons with policy-driven issuance and rapid revocation.
In practice, teams that mix code-stored secrets, CI variables, and ad hoc developer overrides usually end up with multiple shadow copies before the first incident response playbook is tested.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses hardcoded and overexposed non-human credentials. |
| CSA MAESTRO | IAM-04 | Covers workload identity and secret handling for automated agentic systems. |
| NIST CSF 2.0 | PR.AC-1 | Access control fails when secrets are copied into uncontrolled pipeline locations. |
Restrict secret access to approved systems and verify usage through continuous access review.
