Notifications
Clear all
Topic starter
25/06/2026 5:05 pm
TL;DR: Static secrets, weak rotation, over-provisioned access, and poor lifecycle handling remain common secrets management failures in application security, according to Entro Security. The underlying problem is not just exposure, but governance that still assumes secrets behave like stable, reviewable assets.
NHIMG editorial — based on content published by Entro Security: Beyond the basics: advanced insights into secrets management challenges
Questions worth separating out
Q: What breaks when secrets are hardcoded in code repositories?
A: Hardcoded secrets turn a codebase into a distribution point for credentials.
Q: Why do static secrets increase lateral movement risk?
A: Static secrets stay valid long enough for attackers to reuse them after initial exposure.
Q: What do teams get wrong about secrets rotation?
A: Teams often treat rotation as a scheduling problem instead of a dependency problem.
Practitioner guidance
- Remove embedded credentials from source code Scan repositories for hardcoded keys, tokens, and passwords, then replace them with runtime injection and build-time secret references.
- Tie rotation to revocation and service compatibility Set rotation intervals based on application dependency, not arbitrary calendar timing, and ensure old credentials are invalidated when new ones go live.
- Limit export rights from vaults and clusters Review which roles can read, export, or replicate secrets from vaults, Kubernetes namespaces, and CI/CD systems.
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 for handling hardcoded secrets in application repositories and delivery pipelines
- Practical discussion of rotation timing, revocation trade-offs, and application compatibility issues
- Kubernetes and vault access pitfalls, including RBAC scope and secret export risk
- Context on secrets inventory, classification, and monitoring approaches across environments
👉 Read Entro Security's analysis of advanced secrets management mistakes →
Secrets management mistakes: where do controls fail in practice?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:35 pm
Secrets are identity objects, not static configuration. The article is really describing a governance failure, not just a storage problem. Once a credential can be copied, shared, reused, and forgotten, it behaves like an unmanaged non-human identity with its own lifecycle and blast radius. Practitioners should stop treating secrets as passive data and govern them as active access paths.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that detection without revocation leaves material exposure in place.
A question worth separating out:
Q: How should organisations govern secrets in Kubernetes and vaults?
A: They should treat secrets as high-value access objects and restrict who can create, read, export, or replicate them. In Kubernetes and vault environments, RBAC and namespace scoping are only effective if export paths are also controlled. The goal is to reduce blast radius so one compromised secret does not expose the full environment.
👉 Read our full editorial: Secrets management mistakes expose the limits of static control
