How can organisations reduce the risk of repeated secret leaks?

Why Repeated Secret Leaks Keep Happening

Repeated secret leaks usually persist because the underlying problem is structural, not just procedural. Secrets are copied into code, build logs, tickets, chat tools, test fixtures, and automation scripts faster than teams can remove them. The result is secret sprawl, weak ownership, and delayed detection. The Guide to the Secret Sprawl Challenge shows why centralised management matters, while the Shai Hulud npm malware campaign demonstrates how one exposed secret can become a wider supply chain event. Current guidance suggests the issue is not solved by scanning alone because prevention and response must be treated as one control set.

That is also why the control model has to include detection, revocation, and recovery. The NIST Cybersecurity Framework 2.0 remains useful here because it pushes organisations to connect protection with response, not treat them as separate programmes. In the 2024 State of Secrets Management Survey by Akeyless, only 44% of organisations reported using a dedicated secrets management system, and the average time to mitigate a leaked secret was 36 hours, which is far too long for high-frequency CI/CD environments. In practice, many security teams only learn how fragmented their secret handling is after a build pipeline or public repository has already exposed sensitive material.

How to Reduce Recurrence Across the Full Secret Lifecycle

The practical answer is to manage secrets as a lifecycle problem. That means eliminating hardcoded credentials, storing secrets in a dedicated manager, issuing short-lived values where possible, and revoking access automatically when a workload, job, or deployment ends. It also means enforcing least privilege so that a leaked secret cannot access more than the minimum required target set. This aligns well with the OWASP Non-Human Identity Top 10, which treats credential exposure and over-permissioning as linked failure modes rather than isolated events.

A resilient programme usually includes:

• secret discovery in source control, build logs, artefacts, and developer workstations;
• pre-commit and CI/CD scanning for tokens, keys, and certificates;
• ephemeral issuance with automatic rotation and revocation;
• RBAC and PAM reviews for service accounts and automation identities;
• incident runbooks that revoke, replace, and validate affected secrets quickly.

The operational goal is to make the safe path the easiest path. If developers need manual approvals or ad hoc copy-paste workflows, leaks will keep reappearing. The CI/CD pipeline exploitation case study shows how compromised build systems turn one bad secret into repeated exposure, while the 52 NHI Breaches Analysis reinforces that identity failure often becomes incident recurrence when ownership and response are unclear. These controls tend to break down when secrets are embedded in legacy scripts, third-party integrations, or long-running service accounts because revocation then collides with business continuity.

Where the Control Model Breaks Down in Real Environments

Tighter secret controls often increase operational overhead, so organisations have to balance speed against assurance. Best practice is evolving, and there is no universal standard for every environment, especially where legacy applications cannot tolerate short TTLs or automated rotation. In those cases, compensating controls matter: stronger segmentation, stronger monitoring, narrower access paths, and explicit exception handling. The key point is to avoid treating long-lived secrets as acceptable simply because they are common.

Edge cases appear in machine-to-machine integrations, vendor-held credentials, and legacy batch jobs that break when rotated too frequently. Those situations should be documented as risk exceptions with defined review dates, not left as permanent architecture. For organisations building more automated response, the Anthropic report on the first AI-orchestrated cyber espionage campaign is a useful reminder that automation can accelerate both defence and abuse. In the same way, the 230M AWS environment compromise shows how quickly cloud permissions and exposed credentials can scale failure. The right response is not just better tooling, but tighter governance over who can create secrets, where they can live, and how quickly they can be killed when misuse is suspected.

Related resources from NHI Mgmt Group

• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• How should teams reduce the risk from exposed NHI secrets?
• How should security teams reduce secret sprawl on developer workstations?