Topic starter
20/08/2026 5:55 pm
TL;DR: Weak credential handling still drives a large share of cloud incidents, with 22% of overall security incidents in 2025 linked to credentials in public view, according to Cycode. Secrets programs now have to track exposure outside the vault, because detection and rotation matter as much as storage.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “The Best Secrets Management Tools of 2026”.
By the numbers:
- 22% of overall security incidents in 2025 stemmed from credentials in public view.
- 43% of all exposed secrets reside outside code repositories, with 14% found in messaging and collaboration platforms like Slack, Jira, and Confluence.
Key questions
Q: Why do exposed API keys and weak API controls create outsized breach risk?
A: Exposed API keys are powerful because they often grant direct access to applications, data, and automation paths without the friction of interactive login.
Q: How can security teams tell whether secret management is actually working?
A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems.
Q: What breaks when secrets are still stored outside managed vaults?
A: Secrets become easy to reuse across humans, scripts, and agents without a consistent audit trail.
Practitioner guidance
- Map all secret exposure surfaces Inventory repositories, CI/CD pipelines, collaboration platforms, configuration files, and object storage where credentials can appear outside the vault.
- Add validation to secret discovery Require every exposed secret finding to be checked for live status so triage separates stale artefacts from active credentials.
- Shorten credential lifetime aggressively Replace long-lived API keys, passwords, and tokens with dynamic credentials or tightly bounded rotation schedules wherever the system allows it.
Bottom line: Secrets management tools now have to govern exposure as well as storage because credentials leak into code, chat, pipelines, and configuration outside the vault.
Glossary terms: Secrets Sprawl, Secret Validation, Long-Lived Secret, Dynamic credentials
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
20/08/2026 6:35 pm
Vault-only control is an incomplete governance model: a vault governs secret storage, not secret exposure. Once credentials move into code, chat, documentation, or CI/CD logs, the control boundary has already been crossed and the programme is relying on detective coverage it may not have. Practitioners should treat vaults as one layer in credential governance, not the governance model itself.
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.
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should organisations respond when vulnerable code also contains secrets?
A: Treat it as both an application defect and an identity exposure event. Revoke or rotate the exposed credentials, search for reuse across pipelines and services, and investigate whether the secret enabled access beyond the original codebase. The remediation path should follow the credential, not only the repository.
👉 Read our full editorial: Secrets management tools in 2026 expose the limits of vault-only control