Notifications
Clear all
Topic starter
25/06/2026 5:02 pm
TL;DR: Hardcoded secrets, secrets sprawl, weak access controls, and infrequent rotation make Infrastructure as Code a recurring source of exposure, according to Entro Security. Vaults reduce blast radius, but they do not solve lifecycle, logging, or post-retrieval leakage, so secrets governance must extend across the toolchain.
NHIMG editorial — based on content published by Entro Security: Best practices for IaC and secrets security
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: How should security teams prevent secrets from being hardcoded in Infrastructure as Code?
A: Security teams should remove credentials from source files entirely and replace them with runtime references from a secrets system or identity-aware delivery process.
Q: Why do vaults not solve secrets security on their own?
A: Vaults centralise storage, but they do not control where a secret goes after it is retrieved.
Q: What breaks when secrets are spread across multiple repositories and tools?
A: When secrets sprawl across repositories and toolchains, organisations lose the ability to find, classify, and revoke them quickly.
Practitioner guidance
- Remove secrets from source-controlled IaC Replace hardcoded credentials with runtime secret references, and block commits that contain keys, tokens, or passwords in Ansible, Terraform, or related repositories.
- Trace every secret through its post-vault path Document where secrets are injected after retrieval, including logs, command lines, environment variables, and build artefacts.
- Bind secrets governance to pipeline identity Apply least privilege, logging, and approval controls to CI/CD systems that read or distribute secrets.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on organizing secrets across IaC directory structures and variable naming conventions
- A deeper walkthrough of access control patterns for secrets vaults, including least-privilege decisions
- Practical logging and audit guidance for secret creation, retrieval, updates, and deletions
- Context-based rotation considerations for dependencies, privileges, and service relationships
👉 Read Entro Security's blog on best practices for IaC and secrets security →
IaC secrets security: what IAM and NHI teams need to fix?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:30 pm
Hardcoded IaC secrets are not a storage problem, they are a lifecycle failure. Once credentials are embedded in source files, the organisation has already lost control of where they copy, how long they persist, and who can reuse them. That breaks the normal identity assumption that access is issued into a known system and can be revoked from a known system. Practitioners should treat code-embedded secrets as a governance defect, not a convenience issue.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, 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.
A question worth separating out:
Q: How do security teams govern secrets in CI/CD pipelines without slowing delivery?
A: They should treat the pipeline as part of the identity plane and give it only the secrets it needs for a specific build or deployment. Access should be logged, time-bounded, and reviewable, with approval boundaries for changes that affect secret distribution. This preserves delivery speed while reducing uncontrolled credential reuse.
👉 Read our full editorial: IaC secrets security exposes the limits of hardcoded credentials
