Why Secrets Slip Through Every Layer of Your Security Stack

Your security stack is a set of specialists, each guarding one territory. Exposed credentials don't respect the boundaries between them, and 64% of the ones found valid in 2022 were still valid four years later.

TL;DR

• Multiple locations, one credential: An API key moves from a developer's laptop to a repo, pipeline logs, a ticket, and a teammate's config; each copy carries the same access, and no single tool tracks all five.
• Every tool has a job. Secrets fall between them: Your security stack is built from specialists, but no single tool is designed to track a credential across every environment it touches.
• 28% happens where no scanner looks: GitGuardian's State of Secrets Sprawl 2026 found 28% of secrets incidents occur entirely outside code repositories, in collaboration and productivity tools.
• 64% still valid four years later: Of secrets found valid in public repos in 2022, more than 64% were still valid when retested in January 2026. Revocation needs cross-tool context nobody owns.

Follow one API key for a month. It gets created on a developer's laptop, committed to a repository, echoed into a pipeline log, pasted into a ticket during an incident, and copied into a teammate's local config. Five locations hold the same credential, with the same privileges anywhere that credential remains valid. Each copy creates another path to compromise. Once an unauthorized person or system reaches one of them, the organization has to scope the credential across every place it traveled. This is secrets sprawl in miniature: one credential, five copies, no map of where they all ended up.

Now overlay your security stack on that itinerary; the repo scanner saw the commit, the endpoint agent watched the laptop for hostile behavior, and the vault protected its own enrolled copy, faithfully. Each control did its job inside its territory. The problem is that the key never stayed in one.

The security stack is fragmented by design

Modern security organizes itself into territories, and the specialization is deliberate:

• Application security: finds the flaws in code.
• Endpoint detection and response (EDR): watches machine behavior.
• Identity and access management (IAM): governs who should hold access.
• Vaults: protect the credentials enrolled in them.
• Cloud security: governs infrastructure and permissions.
• Security information and event management (SIEM): correlates what all of it produces.

That division of labor is why each control works. A scanner that also tries to be an endpoint agent would do both jobs worse. Fragmentation is the design principle that makes the stack possible; specialists beat generalists at every individual layer.

The design has one blind spot, and it is structural. Territories can only protect what stays inside them.

Leaked credentials do not respect the map

A long-lived credential can cross environment boundaries while retaining its authority wherever it remains valid. The key flagged in your repository may also sit in a public fork, an old build artifact, and the config of a local AI tool, and each copy carries the same access as the one you found. Movement is now the norm rather than the exception. GitGuardian's State of Secrets Sprawl 2026 found that 28% of secrets incidents happen exclusively outside code repositories, in the collaboration and productivity tools where no repository scanner will ever look.

Crossing boundaries does something subtle to detection. When exposures surface in different tools, each arrives as its own finding. Three alerts in three consoles might represent three compromised credentials or one credential exposed in three places. A control limited to a single telemetry source cannot determine the full scope on its own, because answering that question requires visibility across those environments.

And when an attacker eventually uses a copy, every control may behave correctly. The login succeeds because it was built to succeed. That is what separates credential compromise from most other attack paths: it looks like legitimate access.

The seams have no owner

The objection writes itself: plenty of tools now scan for secrets. Repository platforms do. Some application security suites carry a secrets feature. Every one of those catches is welcome, but a secrets feature scoped to a single surface can answer only that surface's question. On its own, it cannot establish everywhere else the credential exists or whether the exposure has been fully remediated.

The persistence data shows what happens to questions nobody is assigned. Of the valid secrets detected in public repositories in 2022, more than 64% were still valid when retested in January 2026. Four years exposed, unrevoked. Revoking a credential takes context no single territory holds, starting with what breaks on rotation and who owns the fix. Findings that fall in the seams stay in the seams.

What sitting in the seams would mean

Closing the gap means treating the credential as one connected object across everything it touches. For each one, that means every location where a copy exists, whether separate exposures are the same secret, whether it still works, who owns it, and what it can access.

A layer like that strengthens the territories rather than competing with them. A vault gets stronger when the organization can see which credentials escaped it, and identity governance gets stronger when it can account for every credential its identities carry.

Where the full argument lives

Our ebook, The Secrets Problem: Everyone's Dependency. No One's Job, traces this gap across every layer of the security stack. It shows where each control's visibility ends, what happens when credentials cross those boundaries, and why secrets security needs an owner of its own.

Close the seams your security stack can't see across. Book a demo with our team.

FAQs

What is a security stack?

A security stack is the set of specialized tools an organization layers together to protect its systems: application security scanners, endpoint detection and response (EDR), identity and access management (IAM), vaults, cloud security tools, and SIEM. Each tool is built to excel inside one territory rather than cover everything.

Why do security tools miss credentials that move between them?

Because each tool only sees its own territory by design. A repository scanner catches a credential when it's committed to code, an endpoint agent watches for hostile behavior on a laptop, and a vault protects the copy enrolled in it, but a credential that travels across a laptop, a repo, a pipeline log, a support ticket, and a teammate's config crosses five different blind spots, and no single tool sees the whole path.

What percentage of secrets incidents happen outside code repositories?

According to our own State of Secrets Sprawl 2026 report, 28% of secrets incidents happen exclusively outside code repositories, in collaboration and productivity tools like Slack, Jira, and Confluence, none of which a repository scanner ever looks at.

How long do exposed credentials stay valid after they're discovered?

Often for years. Of the valid secrets GitGuardian detected in public repositories in 2022, more than 64% were still valid when retested in January 2026, four years later.

Why does credential compromise look like a normal login instead of an attack?

When an attacker uses a valid stolen credential, every control behaves exactly as designed; the login succeeds because it was built to succeed for that credential. That's what separates credential compromise from most other attack paths: nothing in the stack flags it as wrong.

Who is responsible for revoking a leaked credential?

Responsibility is often distributed across teams. Security may discover the exposure, while the credential owner or platform team has to revoke it, and an application owner may need to determine what will break when it rotates. No single security tool necessarily holds all of that context, which can make leaked credentials harder to remediate quickly.