Topic starter
20/08/2026 5:55 pm
TL;DR: Weak secrets management now drives a large share of cloud incidents, with Cycode citing 22% of overall security incidents in 2025 stemming from credentials in public view. The real problem is not storage alone but secret sprawl across code, CI/CD, and collaboration tools, where rotation and detection must work together.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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