The Container Secrets Crisis: Keys Under the Doormat of Modern Infrastructure

Every year, the security company GitGuardian scans the world's public code and counts the secrets left lying in it — API keys, database passwords, cloud credentials, tokens — hardcoded where anyone can find them. In 2024 it found 23.8 million new hardcoded secrets added to public GitHub repositories, a 25% jump over the year before, which was itself up 28% on the year before that. These are not obscure test keys. A striking share carry real power: 96% of leaked GitHub tokens had write access, and OpenAI API key leaks surged more than a thousandfold as developers rushed AI into their code. Worst of all is the persistence — roughly 70% of the secrets detected in 2022 were still valid two years later, meaning most of them were never rotated, never revoked, still working, still exposed.

This is the container secrets crisis: the modern practice of scattering credentials — the literal keys to every system — throughout code, container images, configuration files, and command histories, in a way that leaves them, in effect, under the doormat of the whole infrastructure. It is one of the most common and least glamorous security failures in existence, and its ubiquity is a direct consequence of how modern software is built.

Why secrets sprawl

A secret is any credential that grants access — a password, a key, a token. In principle, secrets should live in exactly one protected place and be handed to systems only at the moment of use. In practice, the modern development workflow scatters them everywhere, for reasons that are individually reasonable and collectively catastrophic.

The container is the emblem. To run, a containerized application needs its database password, its cloud key, its third-party tokens — and the fastest way to make that work is to bake them into the image, drop them in an environment variable, or paste them into a config file that ships with the code. Each shortcut solves the immediate problem: the app runs. Each also copies the secret into a new place it can leak from. Container images get pushed to registries, layered, cached, and shared, and a secret baked into an early layer persists in the image history even if a later layer "removes" it — a door someone painted over but never sealed. The same dynamic plays out in Git: a key committed once lives in the repository's history forever, retrievable long after it was "deleted" from the current files, which is exactly why the public-GitHub numbers are so large. The secret was never really removed. It was just moved behind a wall that anyone can walk around.

Why it is worse than it looks

The raw counts understate the danger, because a leaked secret is not a static exposure; it is a live door. The GitGuardian findings sharpen this in three ways. First, scope: with 96% of leaked tokens carrying write access, most exposed credentials do not merely reveal data — they grant the power to change it, delete it, or pivot deeper into the system. Second, persistence: because ~70% of detected secrets stay valid for years, the window of exposure is not the minute before someone notices; it is the entire lifetime of an un-rotated credential, which is often the entire lifetime of the system. Third, reach: GitGuardian found tens of thousands of secrets embedded across millions of PyPI package releases, which means secrets are leaking not only from applications but from the dependencies applications pull in — a secret in a package you import is a secret you are now exposed by without ever having seen it. This is where the crisis touches the series' Trust Inversion (#59): the trusted dependency is, once again, the unexpected attack surface.

Why the automated era makes it acute

The container secrets crisis is intensifying for the same reason most modern security problems are: automation has removed the human friction that used to limit the damage. Code is generated faster, by more people and increasingly by AI assistants, and generated code cheerfully hardcodes a placeholder key that a hurried developer forgets to replace — the thousandfold surge in leaked OpenAI keys is partly the sound of AI-assisted development leaking the credentials to AI services. Deployment is automated, so a secret committed once propagates through build pipelines, image registries, and running containers within minutes, into more places than any person is tracking. And the sheer volume of code and dependencies has grown past the point where manual review could plausibly catch a stray credential. The friction that used to make leaking a secret slow and noticeable is gone; leaking one is now frictionless and silent.

What actually fixes it

The remedies are well understood and, revealingly, mostly unadopted — which tells you the problem is cultural and economic, not technical. Secrets should never be in code or images at all; they should live in dedicated secret managers and be injected at runtime, so the credential never touches the repository or the layer. They should be short-lived and automatically rotated, so that a leaked secret is a door that locks itself shortly after it opens rather than one that stays ajar for years. Their scope should be minimized — a credential that can only do the one thing it needs is a far smaller catastrophe when it leaks than a token with write access to everything. And repositories and images should be scanned continuously, on the assumption that secrets will be committed by accident, because the numbers prove they will.

None of this is exotic. The container secrets crisis persists not because the fix is unknown but because doing it right is slightly slower than doing it wrong, and the cost of doing it wrong is deferred, diffuse, and invisible until the breach — the same asymmetry the series keeps finding under every unglamorous failure. The keys are under the doormat because putting them there was easy, and because, most days, nothing bad happens. The 23.8 million secrets counted last year are the measure of how long "most days" can last, and of how many doors are standing open, right now, that no one has thought about since the day they shipped.

This is article #63 in The IUBIRE Framework series. The Container Secrets Crisis was articulated by IUBIRE V3 in artifact #3378 — "A Technical Deep Dive" (April 2026). Real-world data: GitGuardian's State of Secrets Sprawl (23.8M new hardcoded secrets in public GitHub in 2024, +25% year-over-year; ~70% of secrets detected in 2022 still valid in 2024; 96% of leaked GitHub tokens carrying write access; a >1,000× surge in leaked OpenAI API keys; ~56,866 secrets across 5M PyPI package releases).

Next in series: The Tool Perfectionism Paradox (#64)