Secret Sprawl: How to Detect and Prevent It (2026 Data)

What secret sprawl is

An engineer retrieves a database credential from the company vault, pastes it into a debug command, and later copies the terminal output into a Confluence incident page. The vault authenticated the request, logged the read and never lost control of its own storage. The organization still has a working database password on a wiki page the whole department can read.

That is secret sprawl: not one dramatic leak, but credentials multiplying through ordinary work. Each copy is as good as the original. Nobody tracks the copies, so nobody revokes them, and the places they land (tickets, pages, chat threads, CI logs) are read by far more people than the vault ever was, and kept for years.

Three terms help when people argue about it. A secret is anything that grants access by being known: an API key, a token, a password, a private key, a connection string with a password in it. An occurrence is one copy in one place. An incident is one secret, however many copies it has. Sprawl is occurrences outgrowing incidents: one key, twenty copies, and every copy has to be found, because each one keeps working until the key itself is revoked.

It is not the same as “we don’t use a vault”. GitGuardian’s 2025 report found that 5.1% “of repositories using secrets managers still leaked secrets in 2024”. The vault protects the canonical copy. Sprawl is everything that happens after a person or a build reads it.

Secret sprawl in numbers (2026)

All figures from the primary reports, fetched on 1 November 2026.

Two numbers matter most for planning. The 4% overlap means a code scanner and a collaboration-tool scanner find almost entirely different secrets: you cannot cover one surface with the other. And the 64% means the hard part is not finding leaks but closing them; a finding that sits in a queue for a year is a working key for a year.

Where secrets sprawl: the places to look

Every place on this list has a reason people paste credentials into it. That reason is also where prevention has to start.

The collaboration rows deserve the most attention because they are the least watched and the most read. A git repository is read by the people who build it. A Jira project or a Confluence space is read by the whole department, by contractors, sometimes by customers through a portal. Our earlier look at secrets in Jira issues goes through how they get there; the credential leak guide for Confluence and Jira covers the habits behind it.

How to detect secret sprawl

Detection works in layers, from the cheapest point (before the secret is saved anywhere) to the most expensive (finding a copy that has been sitting somewhere for years).

1. At the keyboard and at commit. OWASP’s Secrets Management Cheat Sheet says to “consider enabling secrets detection at the developer level to avoid checking secrets into code before commit/PR”. A pre-commit hook and the code host’s push protection stop most new code leaks before they exist.

2. Every repository’s history. Run a full-history scan on all repositories, internal ones first: GitGuardian finds internal repositories about six times likelier than public ones to contain hardcoded secrets, and nobody outside the company is looking at them for you.

3. Where people write, not only where they code. Jira, Confluence and chat need their own scanner. In Atlassian Cloud the built-in option is Atlassian Guard Premium, whose sensitive data detection covers credentials, which Atlassian describes as “data like API tokens and private keys”. Its own documentation lists the gaps: it does not scan “Confluence whiteboards and databases” or “text entered into our fields from third-party apps”; in Jira, “we don’t scan fields that haven’t changed”; and attachments are skipped when they are over 5 MB, compressed or archived. Its Findings page combines real-time monitoring with “full-site content scans”, so it can look at existing content too. Without Guard Premium, nothing in Jira or Confluence scans for credentials; a Marketplace app or an external scanner has to.

4. Rank, but do not discard. Validating a finding (does the key still work?) is the fastest way to rank a queue. It is a bad way to empty one: GitGuardian reports that “46% of critical secrets are missed by validation-only prioritization”, because many secret types have no safe way to test them.

5. Measure the right thing. A falling number of findings can mean fewer leaks, or a scanner that lost coverage. Track findings by place, time to revoke, and repeat leaks of the same credential, and test the scanner with known fake secrets now and then; our guide to testing detection without live credentials shows how.

We tested what pattern scanners catch

Almost every secret scanner, including ours, is a set of patterns: a known prefix, a length, an alphabet. We wanted to know how far that gets you on the kind of text people actually paste into Jira and Confluence, so we measured it.

Method. We wrote 28 leak shapes the way they appear in tickets and pages: a comment with an AWS key pair, a runbook line export GH_TOKEN=…, a pasted .env, a curl -u command, a Basic auth header, a password in a table, a password in a sentence. Each value was random, generated in the vendor’s published shape (prefix, length, alphabet), 50 values per shape, 1,400 fake leaks in all. We ran them through two scanners on 1 November 2026: the scanner inside Secret Sentinel (its detection code at repository commit 57c1931, with the same credential rules as the production versions) and our free API key leak checker, which knows 47 formats. A leak counts as found when the scanner reports anything in it. The generator, the runners and the raw counts are kept with our research notes.

Every shape, with how many of its 50 fake leaks each scanner found:

What the numbers say:

• A prefix is what makes a secret findable. AKIA, ghp_, xoxb-, sk_live_, glpat-: when the vendor stamps its tokens, a scanner finds them every time, wherever they are pasted. The few random misses (two OpenAI keys, one Google key, two Telegram tokens) were all values ending in a hyphen, where the rule’s word boundary does not fire.
• A password without a label is invisible. Neither scanner found a password in a sentence, in a table, after docker login -p, in curl -u, in a .env line named DB_PASSWORD, or base64-encoded in a Basic header: 0 of 300 for each. The only no-prefix catch was the kubeconfig line, because Secret Sentinel has a rule for token: followed by a value. These are exactly the shapes of a quick message to a colleague.
• Coverage lists differ, so check yours. Secret Sentinel’s built-in rules have no pattern for Google API keys, Atlassian API tokens, Telegram bot tokens or Azure storage keys; the free checker has all four. Ask any scanner vendor for the list, then test it with fake values in the shapes your company uses.

The conclusion is not “scanners don’t work”. It is that a scanner is a net for tokens, and prevention has to deal with passwords, mostly by not having shared human passwords for services at all, which is where the next section starts.

How to prevent secret sprawl

Ranked by how much sprawl each control removes, most first.

1. Take people out of the path. OWASP puts it plainly: “it is better to limit or remove the human interaction with the actual secrets.” A credential that no person ever sees cannot be pasted. Where the platform supports it, workloads should authenticate with their own identity (cloud workload identity, OIDC from CI to the cloud) instead of a stored key.

2. Make credentials short-lived. OWASP: “Dynamic secrets should be used where possible to reduce the surface area of credential reuse.” A token that expires in an hour turns a leak in a ticket from a standing risk into a short one. For the rest, “regularly rotate secrets so that any stolen credentials will only work for a short time.”

3. Share access, not values. When a colleague needs a credential, grant them access to it in the vault, or give them a link to the vault entry. A pasted value is a copy; a link is not. Write this into runbook templates: a placeholder like <from vault: payments/db> where people would otherwise paste the value.

4. Stop secrets where they are typed. Pre-commit hooks and push protection for code; for Jira and Confluence, a scanner that acts when content is saved and removes the value from the page, not one that reports a week later. Remember the test above: this catches tokens, not passwords.

5. Keep secrets out of logs. OWASP’s list says secrets must “never be logged”. Masking in CI only hides values it already knows, so do not print environments, and turn off shell tracing around credential handling.

6. Retire shared human passwords. The shapes no scanner caught (a router password, a Grafana admin, docker login -p) are shared passwords used by people. Single sign-on, per-person accounts and a password manager for the few that are left remove the reason to paste them.

7. Use encrypted config instead of plaintext files. For teams that keep configuration in git, encrypting each value removes the plaintext .env that keeps getting committed; envseal is our open-source take on it.

When you find one: the response that actually closes it

Finding a secret is the start. The order matters:

1. Revoke the credential at its source (the cloud console, the vendor dashboard). OWASP: “Keys that were exposed should undergo immediate revocation.”
2. Issue a replacement and deploy it to whatever legitimately used the old one.
3. Remove the copies, every occurrence, not just the one that was reported. Deleting the text does not revoke the key, and Jira and Confluence keep history: old page versions and issue history still hold the value.
4. Check the logs of the service the credential opened for use between the leak and the revoke.
5. Record it: where it leaked, why, how long it was valid, so the same runbook does not leak it again next quarter.

Our guide to rotating credentials after a leak goes through each step by credential type.

Where our tools fit, and where they don’t

Secret Sentinel scans Jira issue summaries, descriptions and comments, and Confluence pages, blog posts and comments, when they are created or edited, and replaces each credential it recognizes with a marker such as [REDACTED by Secret Sentinel: github_token, ghp_****1a2b]. It can open a Jira security incident so someone owns the rotation, and it runs on Atlassian Forge, inside your site. What it does not do, so you can plan around it:

• It acts on new and edited content; it does not sweep years of old pages, attachments or page history. For existing content you need a full-site scan (Guard Premium’s Findings, or an external scanner) once, then Secret Sentinel keeps new leaks from piling up.
• It finds known credential formats, not passwords in prose, as the test above shows. The four formats it missed (Google, Atlassian, Telegram, Azure storage) can be added today as custom patterns in the Advanced edition.

Install Secret Sentinel for Jira · Install Secret Sentinel for Confluence

To check a snippet before you paste it into a ticket, our free API key leak checker runs entirely in your browser, sends nothing anywhere, and gives you a redacted copy to paste instead.