Notifications
Clear all
Topic starter
24/06/2026 10:02 pm
TL;DR: Secrets management platforms do more than store API keys and tokens, but scanning, rotation, alerts, and dark web checks still leave lifecycle, context, and approval gaps that attackers exploit, according to Entro Security. The core issue is not storage alone but governance of exposure, reuse, and revocation across applications and cloud environments.
NHIMG editorial — based on content published by Entro Security: What are secrets management tools and platforms?
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should security teams govern secrets across code, pipelines, and collaboration tools?
A: Security teams should treat secrets as governed identities, not static strings.
Q: Why do leaked secrets remain dangerous after detection?
A: Detection only proves that a secret is exposed.
Q: What do security teams get wrong about secrets vaults?
A: They often assume the vault is the control.
Practitioner guidance
- Map every secret to an accountable owner Require a named system owner, business purpose, and expiry condition for each API key, token, and certificate so review does not stop at storage inventory.
- Expand scanning beyond source code Include CI/CD runners, Slack, Jira, Confluence, container images, and cloud configuration files in discovery so leaks outside repositories are not missed.
- Automate revocation after exposure Connect detection to disablement or rotation workflows so a leaked credential is withdrawn before attackers can reuse it across services.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Platform-specific descriptions of how its secret scanning and enrichment workflow operates across cloud services and collaboration tools
- Implementation examples for automated rotation, alerting, and remediation inside real enterprise environments
- Vendor-specific coverage of Azure Key Vault, AWS Secrets Manager, and Google Cloud Secret Manager integration patterns
- Dark web scanning workflow details that go beyond the governance framing in this analysis
👉 Read Entro Security’s blog on secrets management tools and platforms →
Secrets management tools and platforms: where do controls still fail?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:50 am
Secrets management is really non-human identity governance in disguise. API keys, tokens, and certificates behave like identities because they carry access, scope, and lifecycle obligations. The article treats them as storage objects, but practitioners should read them as governed access instruments that need ownership, rotation, and retirement. That framing is the difference between vault administration and identity security discipline.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 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.
A question worth separating out:
Q: How do organisations know whether secrets management is actually working?
A: Look for fewer exposed duplicates, faster revocation after discovery, and clear ownership for every credential. If secrets still appear in multiple locations or remain active after offboarding, the programme is producing alerts without reducing attack surface. The goal is measurable reduction in standing exposure, not just more findings.
👉 Read our full editorial: Secrets management platforms expose the real lifecycle problem
