Why do Docker secrets still leak in mature CI/CD environments?

Why This Matters for Security Teams

Docker secrets are often assumed to be safe because they are marked as secrets and handled by the platform, but that assumption fails when the wider delivery system is noisy, shared, or poorly segmented. The real risk is not the secret object itself, but every place it can be echoed, cached, copied, mounted, or inherited during build and deployment. That makes this a pipeline governance issue as much as a container issue. NIST guidance on secure software development and OWASP Non-Human Identity Top 10 both point to the same core problem: machine credentials and automation identities need explicit control, not informal trust.

Teams also underestimate how often secrets cross trust boundaries through logs, artifact stores, cache layers, and reused configuration. Mature CI/CD does not remove exposure by default; it only reduces it when the pipeline is designed to keep sensitive values ephemeral and invisible to everything that does not strictly require them. In practice, many security teams encounter this only after a build log, image layer, or shared runner has already exposed the secret to a broader audience than intended.

How It Works in Practice

Docker secrets leak when the secret lifecycle is longer than the execution step that needs it. A secret may be injected correctly at runtime, yet still appear earlier in the process through shell expansion, debug output, environment inheritance, or a build stage that accidentally copies it into an image layer. The issue is especially common when teams use the same compose files, templates, or runner images across multiple projects without strict separation of environments.

Operationally, the safest pattern is to keep secrets out of source control, out of build arguments, and out of image history. Use ephemeral delivery where possible, mount secrets only for the process that needs them, and revoke or rotate them if a runner, job log, or artifact is exposed. That also means treating CI/CD service accounts as non-human identities with scoped privilege, monitored access, and distinct credentials per system or pipeline. The Anthropic report on the first AI-orchestrated cyber espionage campaign reinforces a broader lesson: automation can scale both control and misuse, so identity and secret governance must be engineered into machine workflows.

• Separate build-time inputs from runtime secrets.
• Disable verbose logging around secret handling paths.
• Use isolated runners and short-lived credentials for sensitive pipelines.
• Scan images, layers, and artifact stores for secret remnants before release.
• Restrict who can read logs, cache, and deployment metadata.

These controls tend to break down when teams rely on shared runners with permissive debug settings and long-lived reusable environment files, because one job can expose another job’s sensitive material.

Common Variations and Edge Cases

Tighter secret handling often increases pipeline overhead, requiring organisations to balance delivery speed against isolation, rotation, and auditability. That tradeoff becomes visible in high-churn environments where teams reuse templates aggressively or expect the same secret to work across development, test, and production.

Current guidance suggests that there is no universal standard for every CI/CD stack, especially when legacy compose workflows, self-hosted runners, and third-party orchestration tools are mixed together. In those environments, the weakest link is often not Docker itself but the surrounding control plane: shared credentials, inherited environment variables, or operators who can read job output after execution. This is where NHI governance becomes practical, because pipeline identities should be unique, scoped, and reviewable rather than treated as shared infrastructure glue.

One common edge case is when secrets are not leaked directly but are preserved in layers, caches, or debug artifacts that later become accessible through a separate process. Another is when teams move fast in feature branches and accidentally normalize insecure patterns that are then copied into production templates. The most reliable response is to define where secrets may exist, who may observe them, and how quickly they expire, then verify those assumptions continuously rather than at release time.

Related resources from NHI Mgmt Group

• Why do short-lived tokens still create major risk in CI/CD environments
• Why do developer tokens and CI/CD secrets create such high risk in agentic environments?
• What breaks when Kubernetes deployments still depend on shared CI/CD secrets?
• How do I implement secrets scanning in a CI/CD pipeline?