Tag: GitHub security

In 2025 alone, security firm GitGuardian detected 28.65 million new hardcoded secrets exposed in public GitHub commits — a 34% increase year over year and the largest single-year jump the company has recorded in five years of publishing its annual State of Secrets Sprawl report. Since 2021, that number has grown 152%, far outpacing the 98% growth in GitHub’s active developer base over the same period. Secrets sprawl isn’t a hypothetical DevOps hygiene problem anymore. It’s accelerating faster than most security teams can respond to it, and AI-assisted development is a large part of why.

The financial stakes keep climbing alongside it. IBM’s newly released 2026 Cost of a Data Breach Report puts the global average cost of a breach at $4.99 million, a 12% increase over the prior year and a new record high. In IBM’s 2025 edition, breaches where compromised credentials were the initial access vector carried a $4.67 million average cost on their own, and organizations took an average of 246 days just to identify and contain them. A single hardcoded credential, sitting in a repository or a config file for months, is exactly the kind of quiet, slow-burning exposure that produces numbers like these.

Why Secrets Sprawl is Getting Worse, Not Better

The intuitive assumption is that better tooling and more awareness should be shrinking this problem over time. The data says the opposite is happening, and AI-assisted coding is a specific, identifiable accelerant.

GitGuardian’s 2026 report found that secrets tied to AI services grew 81.5% year over year, making them the fastest-growing category of leaked credentials in the entire dataset. Model context protocol (MCP) configuration files, which became a de facto standard for connecting LLMs to external tools and data sources in 2025, already had 24,008 unique secrets exposed in their first year of widespread use. The report links this pattern partly to official documentation that suggests passing API keys as command-line arguments or storing them directly in JSON config files. The report also found that commits produced with AI coding assistance leaked secrets at roughly twice the rate of the GitHub-wide baseline. This was not because AI tools are malicious, but because they generate working code quickly, including secrets, without the natural pause a developer might take to ask whether a credential belongs in that file.

The consequences of this pattern aren’t abstract. GitGuardian’s research points to the Smithery.ai incident as a concrete illustration: A path-traversal vulnerability in an MCP registry exposed overprivileged tokens, granting arbitrary code execution across more than 3,000 hosted servers from a single flaw. That’s what secrets sprawl actually costs when it intersects with infrastructure that’s more centralized and more automated than the credentials scattered across it were ever designed to be.

Two other findings from the same report should reshape how security teams think about the shape of this problem, not just its size. First, internal repositories are six times more likely than public ones to contain hardcoded secrets; the sprawl problem is worse exactly where fewer external eyes are watching. Second, and more troubling, 64% of secrets that leaked in 2022 are still valid and exploitable today. Detection without remediation and rotation isn’t solving anything; it’s cataloging a problem that never actually gets fixed.

Step One: Get Secrets out of Code Entirely

The starting point for any serious secrets program is removing hardcoded credentials from source control and configuration files and centralizing them in a purpose-built secrets manager — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault or Google Secret Manager are the common choices, and the specific product matters less than the discipline of having exactly one control plane rather than credentials scattered across a dozen tools and files.

In practice, this means infrastructure code references a secret at runtime instead of embedding the value directly:

• data “vault_generic_secret” “db_creds” {
• path = “database/creds/readonly”
• }
• resource “aws_db_instance” “app” {
• identifier = “appdb”
• username = data.vault_generic_secret.db_creds.data[“username”]
• password = data.vault_generic_secret.db_creds.data[“password”]
• }

The credential itself never touches version control. Terraform state still needs its own protections — state files can contain resolved secret values — but that’s a narrower, more tractable problem than an organization-wide habit of pasting API keys directly into .env files and Terraform variables under deadline pressure.

Step Two: Enforce Least Privilege Inside the Vault Itself

Centralizing secrets in one place is necessary but not sufficient. Without access controls, a single compromised service account can retrieve far more than it should ever need, turning one small breach into a much larger one. Fine-grained policies scoped to exactly what each service or role requires are what actually limit the blast radius:

• path “database/creds/production” {
• capabilities = [“read”]
• allowed_parameters = {
• “role” = [“readonly”]
• }
• }

The principle here is simple and easy to state but consistently hard to enforce in practice: A service that only ever needs read access to a database should have no path, under any policy, to a credential capable of writing to it. Every broad grant made ‘just in case’ during an incident and never walked back afterward is exactly the kind of standing risk that GitGuardian’s “64% still valid” finding describes at scale.

Step Three: Make Secrets Short-Lived by Default

Static, long-lived secrets are dangerous specifically because they don’t expire on their own. A credential leaked once in 2022 that nobody rotated is, per the data above, still a live risk in 2026. Dynamic secrets flip this: Instead of a fixed, standing credential, the secrets manager generates a short-lived one on demand, tied to a specific request, that expires automatically.

HashiCorp Vault’s database and cloud secrets engines are a common way to implement this — for example, generating a temporary AWS IAM identity scoped to a single task, valid for a bounded window, rather than handing a service a permanent access key it holds indefinitely. For secrets that genuinely can’t be made dynamic (some third-party API keys, for instance), a rotation strategy modeled on blue/green deployments works well in practice: Maintain both a current and a next-version secret, validate that the new one works end-to-end, then cut over and revoke the old one rather than rotating in place and hoping nothing breaks mid-transition.

The goal in both cases is the same: Shrink the window during which a leaked credential is actually useful to an attacker, since detection and remediation alone clearly aren’t keeping pace with the volume of secrets being created.

Step Four: Assume You’ll Need to Prove What Happened

A secrets manager without audit logging tells you what secrets exist, but nothing about who accessed them, when or whether that access was expected. Enabling audit devices — piping access logs to a SIEM, Splunk instance or equivalent — turns “we think this credential might be compromised” into “we can see exactly when and how it was used,” which is the difference between a fast, contained response and a slow, uncertain one.

This matters more, as AI agents get direct access to infrastructure. An agent with a standing credential and no logged trail of what it did with that credential is a much harder incident to investigate than one whose every access is recorded against a specific task and timestamp.

A Practical Playbook

Bringing this together into a sequence a team can actually execute:

Discover What’s Already Exposed: Run a secrets-scanning tool such as GitGuardian or TruffleHog across your full repository history, not just the current branch. Leaked secrets frequently persist in old commits long after the file that contained them was ‘fixed’. Given that 64% of secrets leaked in 2022 are still valid, assume old findings are still live until you’ve confirmed otherwise.

1. Remove and Rotate, Don’t Just Delete: Purging a secret from source history without rotating the underlying credential leaves the exposure intact — the value is already out, likely already scraped and cached elsewhere. Rotate first, then clean the history
2. Stand up a Single Secrets Manager: Consolidate into one control plane rather than a patchwork of environment variables, CI/CD secret stores and cloud-provider-specific tools that nobody has a complete inventory of.
3. Apply Least-Privilege Policies From Day One: Default every new service account and role to the narrowest access that lets it function and require an explicit, logged decision to widen it — never the reverse.
4. Convert Static Secrets to Dynamic Ones Wherever the Secrets Engine Supports It: Start with the highest-value targets. Database credentials and cloud IAM roles are usually both the most common and the most damaging if leaked.
5. Automate Rotation for Everything That Can’t be Made Dynamic: Implement scheduled rotation, blue/green cutover and automatic revocation of the previous version once the new one is confirmed to be working.
6. Enable Audit Logging and Route it Somewhere Your Security Team Actually Monitors: A log nobody reviews provides the appearance of visibility without the substance of it.
7. Pay Specific Attention to AI Tooling: Treat MCP configuration files, AI agent service accounts and CLI-passed API keys as a distinct category worth auditing on their own, given how disproportionately fast that category of leak is growing.
8. Revisit the Entire Inventory Quarterly: Secrets sprawl isn’t a project with an end date. GitGuardian’s own data shows the problem accelerating year over year, which means a program that isn’t actively maintained will fall behind, not stay even.

Conclusion

Secrets sprawl persists not because teams don’t know hardcoded credentials are risky, but because detection alone doesn’t fix anything. A scanner that finds a leaked key changes nothing if nobody rotates it, and the data shows that gap is exactly where organizations are failing. Centralizing secrets in a single control plane, enforcing least privilege inside it, converting static credentials to short-lived dynamic ones and treating audit logging as non-negotiable together close that gap in a way that scanning by itself never will.

With breach costs at a record $4.99 million globally and secrets exposure still growing faster than the developer population producing it, the return on actually finishing this work — not just starting it — has never been more direct.