Topic starter
07/11/2026 11:47 am
TL;DR: Vaults, masking and scanners still miss the runtime moment where secrets actually leak, according to Doppler. Practitioners need controls that govern delivery, use, rotation and revocation, not just storage.
Editorial analysis by NHI Mgmt Group, based on content published by Doppler: “10 common myths about secrets management, risks, and best practices”.
Key questions
Q: Why do secrets in build logs create such a high-risk failure mode for CI/CD pipelines?
A: Build logs are widely distributed, retained, and often visible to developers, operators, and external systems.
Q: How does dynamic secret delivery reduce exposure?
A: Dynamic secret delivery reduces exposure by issuing credentials only when a workload or agent needs them, then revoking or expiring them quickly after use.
Q: How do I stop secrets from leaking at runtime?
A: Stop treating storage as the control boundary and govern the full secret lifecycle instead.
Practitioner guidance
- Enforce runtime secret injection Deliver credentials only when a process needs them, then discard them immediately after use so they do not persist in environment variables, memory or files.
- Block secrets from CI/CD output Remove commands, debug traces and error handling that print tokens or keys, and fail pipelines when log scanning finds credential patterns.
- Automate rotation and revocation Replace manual rotation with policy-driven replacement so leaked credentials can be invalidated quickly across systems that still trust them.
Bottom line: Secrets management fails when teams protect only stored credentials and ignore how those credentials behave once applications begin using them.
Glossary terms: Secrets Management, CI/CD Masking, Secrets Sprawl, Dynamic Secret
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/11/2026 11:48 am
Secrets management fails when teams treat storage as the control boundary: the real control problem begins after a credential is retrieved. Vaults, encrypted stores and masked output do not prevent runtime leakage into memory, logs, build artifacts or developer tooling. The operating assumption that “secured at rest means secured in use” is no longer defensible. The practitioner conclusion is that secrets governance must be measured by how well it controls the credential after delivery, not by how well it stores it.
A few things that frame the scale:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: What is the difference between secret scanning and secret revocation?
A: Secret scanning finds exposure, while secret revocation removes the ability to authenticate with the exposed credential. Scanning reduces blind spots, but revocation is what actually breaks attacker reuse and shrinks blast radius.
👉 Read our full editorial: Secrets management myths leave runtime leaks and breach risk exposed