Secrets Sprawl: Why Your Vault Isn't Enough

Every mature enterprise has a secrets manager. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CyberArk, Akeyless. And every one of those enterprises has thousands of credentials living outside the vault. Your vault is a bank branch; sprawl is the money in mattresses.

Here is the scenario that plays out in incident after incident: the post-mortem reveals a database connection string in a `.env` file that was committed to a private repository eighteen months ago. The vault was there. The rotation policies were configured. The team simply never migrated that one legacy service. One rotation-exempt credential later, and a threat actor who found the repo has standing access to production. The vault did its job. The problem was that not everything was in the vault.

This is the core limitation of a vault-first strategy: a vault is a store, not a discovery mechanism. It protects what you explicitly enrol. It has no opinion about what you do not.

Where the sprawl lives

The container image category deserves particular attention because it is so easy to underestimate the blast radius. A secret baked into a Docker layer is not just in your production cluster — it is in every pull of that image across every environment you run. It is in the CI runner that built it. It is in the container registry. It may be in the CI logs that printed the build output. One credential becomes eight or nine exposure points before the workload runs a single request.

Developer laptops are the other category that tends to get dismissed with "well, we trust our employees." The risk is not malice — it is a stolen MacBook, a compromised home network, or a developer who leaves and does not surrender their local credentials because nobody thought to ask. Long-lived `~/.aws` credentials with production scopes are a decommissioning process problem, not a trust problem.

Why vault-only strategies fail

• The vault is opt-in. Nothing forces a new team to use it. The path of least resistance is a `.env` file.
• The vault has no discovery. If a secret is not there, the vault cannot tell you.
• Rotation is only as good as consumers. Rotate a database password inside the vault and every hard-coded copy breaks — or, worse, silently keeps working.
• Ownership is unclear. Vault entries have permissions, not owners. When someone leaves, their secrets are stranded.
• SaaS secrets are invisible. No vault integration covers the token your Slack app is storing in Slack's infrastructure. The vault's authority stops at the edge of your control plane.
• Compliance evidence is partial. Auditors asking "show me all credentials that were rotated in the last 90 days" will get an answer about your vault, not about the GitHub Actions secret that has been static for three years.

The anatomy of a sprawl audit

Before you can reclaim sprawling credentials, you need to know what you have. A meaningful secrets audit covers six source categories, each requiring a different technique.

# Secrets discovery scope — TigerIdentity connector config
discovery:
  sources:
    code:
      type: git_scan
      targets: [github, gitlab, bitbucket]
      patterns:
        - AKIA[0-9A-Z]{16}           # AWS access key
        - "(?i)api[_-]?key\s*[:=]"  # generic API key pattern
        - "(?i)password\s*[:=]"     # generic password
        - "-----BEGIN.*PRIVATE KEY"  # private keys
      scan_on: push
      scan_history_days: 365          # check all history, not just HEAD

    cicd:
      type: ci_variables
      targets: [github_actions, gitlab_ci, circleci, jenkins]
      pull_cadence: 15m

    containers:
      type: image_layer_scan
      registries: [ecr, gcr, acr, dockerhub_private]
      scan_on: push

    saas:
      type: oauth_grants
      targets: [okta, google_workspace, slack, salesforce]
      pull_cadence: 1h

    cloud_config:
      type: iam_scan
      targets: [aws, gcp, azure]
      pull_cadence: 15m

    secrets_managers:
      type: vault_inventory
      targets: [hashicorp_vault, aws_secrets_manager, azure_keyvault]
      pull_cadence: 5m

The scan produces a deduplicated credential fingerprint inventory — not the raw secrets themselves, but enough metadata to answer the questions that matter: Where does it live? When was it last used? Who owns it? Is it in the vault? How many places is it referenced?

Classifying what you find

Not every credential outside the vault is equally urgent. A useful triage model stacks risk across three axes: exposure, privilege, and freshness.

The rotation problem (and its solution)

One of the subtler failure modes in secrets programmes is what we call "orphaned rotation": the vault rotates a credential on schedule, but some consumers are hard-coded to the old value. The credential changes in the vault. The hard-coded consumers break — or, more dangerously, silently continue working because the old value was written to a config that does not reload until the next deployment.

The solution is not to stop rotating — it is to maintain a consumer manifest for every secret. Before rotating, the system enumerates every workload that uses the credential, verifies each one is wired to the vault SDK rather than a static copy, and only then rotates. If any consumer is hard-coded, the rotation is blocked and the consumer is flagged for remediation.

TigerIdentity's rotation worker does exactly this. It maintains a consumer graph — every workload that holds or references a given credential — and validates live connectivity to the vault before executing any rotation. This eliminates the scenario where a rotation causes a production outage because one legacy service was missed.

A pragmatic reclamation plan

1. Baseline. Scan every source: code, containers, CI/CD, SaaS integrations, cloud provider config. Fingerprint each credential.
2. Attribute. Bind every finding to a human owner via git blame, deployment history, and ownership signals.
3. Prioritise. Exposed > over-privileged > idle > healthy. Fix the exposed set within 24 hours.
4. Consolidate. For the surviving credentials, move to the vault and cut out hard-coded consumers by wiring apps to the vault SDK or a workload broker.
5. Automate rotation. Nothing is really under control until rotation is a scheduled job, not a page in a runbook.
6. Detect drift. New secrets appear every day. A one-time reclamation is worth six months. Continuous discovery is worth years.

Reclamation is a project with a defined end. Drift detection is an ongoing programme. Most teams under-invest in the second because the first feels like the deliverable. In practice, the first-scan remediation is the easy part — it produces visible wins quickly. The hard part is building the automated detection loop that surfaces the next `.env` commit within minutes of the push, before it ever reaches main.

What good looks like at one year

Teams that run a mature secrets governance programme for twelve months tend to converge on a similar set of outcomes. The numbers vary by organisation size and starting state, but the direction is consistent.

• 90%+ of active credentials enrolled in a managed vault. The remaining 10% are documented exceptions with compensating controls.
• Average credential age drops from years to weeks. Automated rotation on a 30-day cadence for most credentials; 7 days for high-privilege.
• Mean time to detect an exposed secret falls from days to minutes. Git-commit scanning catches exposures before the commit reaches any remote.
• Compliance evidence generation becomes automated. "Show me all credential rotations in the last quarter" is a ten-second API call, not a two-week audit sprint.
• Incident response for credential compromise drops from hours to minutes. The system knows every consumer of every credential and can revoke and re-provision in a single automated workflow.

None of these outcomes require a vault you do not already have. They require discovery layered over whatever vault you already run, combined with the automation to act on what you find. That is the gap the vault vendors deliberately leave — and the gap that a dedicated secrets governance layer fills.