Secrets sprawl is the boring breach pattern that keeps working

Of every dozen incidents we are called into, eight involve a credential that was where it should not have been, was older than it should have been, or was scoped more broadly than it should have been. The breach reconstruction is uniformly tedious — somebody finds the credential, somebody uses it, the credential happens to grant more than the attacker hoped, the lateral movement that follows takes hours rather than weeks. The conference talk version of attacks is much more interesting than the production version.

The reason secrets sprawl persists is that no single owner has the full picture. The application team owns application code. The platform team owns the CI pipeline. The cloud team owns the cloud accounts. The vendor management team owns the SaaS contracts. The security team owns the policy that says credentials must be rotated. The credential lives in all five surfaces and is owned by none of them. Until someone is accountable for the inventory, the inventory does not get built.

Practical cleanup proceeds in five passes, each independently valuable.

Inventory the static credentials you have not yet retired. Cloud account access keys, service account passwords, API tokens for SaaS integrations, database connection strings checked into config repositories, vendor admin portal accounts with shared passwords. The starting list is normally longer than CISOs expect. The first useful artefact is a spreadsheet with credential, location, owner, last rotated, and replacement strategy. The “replacement strategy” column is the one that matters — most static credentials have a workload identity or short-lived token replacement that has been available for years.

Replace cloud account static keys with workload identity. Every major cloud platform supports OIDC federation between CI/CD platforms and the cloud. GitHub Actions, GitLab, Buildkite, Jenkins all federate to AWS, Azure, and GCP without static keys. The configuration is a few minutes per repository and the security improvement is qualitative rather than incremental — there is no static key to leak. The only obstacle is “we have always done it this way” and that is an obstacle that pays back per incident not encountered.

Centralise the rest in a secrets manager with rotation. Once you have eliminated the credentials that should not exist, the residual set goes into a secrets manager with rotation policies. AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, GCP Secret Manager — choice depends on existing footprint. The non-negotiable is that rotation actually happens, which means it must be automated. A “ninety-day rotation” policy that requires a human to rotate is a policy that records exceptions, not a policy that rotates secrets.

Detect the credentials that re-emerge. Secret scanning on commits and pipeline runs catches the re-introduction of patterns. The standard tools — gitleaks, trufflehog, GitHub’s native scanning, GitLab’s native scanning — are mature, free, and run in seconds. The configuration question is which patterns to enforce hard versus warn. The pragmatic answer is that anything with a known regular expression for a high-value credential (cloud keys, Stripe keys, internal signing certs) should fail builds; everything else should warn and route to a queue. The metric to watch is mean time from accidental commit to revocation, which should be measured in minutes once detection is wired up.

Treat the SaaS admin portal credentials as their own program. The forgotten layer is the admin login to your dozens of SaaS providers. Most still have shared passwords stored in a password vault, single-factor or weak-second-factor. The work is unglamorous: enumerate the SaaS providers, enforce SSO and MFA via the SaaS admin settings (most support it; a few require an enterprise tier upgrade), eliminate any remaining shared accounts. SaaS-to-SaaS integrations should use OAuth applications with scoped permissions rather than admin passwords behind a service account. The unsexy cousin of zero trust, but the higher-yield work.

A useful framing for the board conversation is that secrets management is the operational discipline that makes the rest of your security architecture work. Conditional access policies are bypassed by a stolen API token. Network segmentation does not stop a credential that grants direct cloud API access. Detection engineering generates alerts that nobody can correlate without a clean inventory. The investment is comparatively small (months, not quarters) and the multiplier is across every other control. We have yet to encounter an organisation that ran this program well and continued to have credential-led incidents in volume.