Hardcoded Secrets in SaaS Codebases and Their Exploitability
Deleted secrets persist in git history, CI/CD logs, and collaboration tools for months.
Deleting a line and pushing a fix does not remove a secret from your repository. It persists in every prior commit that touched that file, which means git history is a permanent artifact of the exposure unless someone actively rewrites it.
From there, the propagation surface is wider than most teams picture. The secret travels to every fork of the repository made before or after the commit, to CI/CD pipeline logs where build systems routinely echo environment variables to stdout, to Docker image layers that preserve filesystem state at build time, to local clones on developer machines, and to backup systems and snapshot archives. Code-search indexers like GitHub's own search and Sourcegraph sweep it up too.
The collaboration tool vector gets overlooked more than it should. Per GitGuardian's 2025 State of Secrets Sprawl, 28% of 2025 incidents originated entirely outside source code, in Slack, Jira, Confluence, and similar platforms. Architecture diagrams, onboarding guides, runbooks, and incident post-mortems routinely contain credentials "for convenience." Those secrets carry outsized risk: 56.7% of secrets found only in collaboration tools were rated critical, compared to 43.7% for code-only incidents.
There is also a persistent misconception about internal repositories. They are not safer. Internal repos contain at least one hardcoded secret 32.2% of the time, versus 5.6% of public repos, making them roughly six times more likely to carry secrets, per GitGuardian 2025. Private repos become public through misconfigurations, ownership transfers, and acquisitions. The "private" label does not hold forever.
By the time a team detects and tries to remediate a secret, it has almost certainly propagated to at least one surface they do not control.
The Scale of the Problem in 2025 and What's Accelerating It
GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025. That is a 34% single-year increase and the largest jump ever recorded. Since 2021, leaked secrets on public GitHub have grown 152%, while the developer population grew only 98%. Secrets are growing faster than the people committing them.
Public repositories are the visible fraction. Given that 32.2% of internal repos contain at least one hardcoded secret, the true count across all codebases is substantially larger.
AI-generated code is a structural accelerant, and it deserves more than a footnote. AI-assisted commits expose secrets at more than twice the rate of human-only commits: 3.2% versus 1.5%, per GitGuardian 2025. The mechanism is a feedback loop. AI tools trained on code that includes hardcoded credentials, combined with developers accepting suggestions without security review, produces a higher commit rate of secrets than either factor would generate alone.
The numbers on AI-service credentials are striking on their own. API keys for LLM providers and AI platforms grew 81% year-over-year, reaching 1,275,105 detected leaks in 2025. In that same year, 113,000 DeepSeek API keys appeared in public repositories, illustrating how a single platform's rapid adoption creates its own credential exposure wave. A December 2025 analysis of 15 production applications built with five major AI coding tools found 69 vulnerabilities across the sample. Separately, Escape.tech scanned over 1,400 vibe-coded production applications and found 58% contained at least one critical vulnerability, including over 400 exposed secrets.
The Model Context Protocol introduces another new surface. GitGuardian found 24,008 unique secrets in MCP-related config files on public GitHub in 2025, with 2,117 verified still valid. That category barely existed in prior years.
The structural forces here are not stabilizing. AI adoption and new tooling paradigms are increasing the commit rate of secrets faster than detection and remediation practices are maturing.
Why Exposed Secrets Stay Exploitable for Months and Years
64% of secrets confirmed as valid in 2022 were still valid and exploitable as of January 2026. Four years of live credentials sitting in public code, per GitGuardian's 2026 analysis. That number should anchor any honest conversation about remediation.
The median time to remediate a discovered leaked secret on GitHub was 94 days, per the Verizon 2025 DBIR. And that figure only counts secrets that teams actually detected with their own tooling.
Rotation is harder than it looks, and the friction is organizational as much as technical. A production API key can be used across dozens of services, pipeline jobs, and third-party integrations; rotating it without a full dependency map breaks things. The engineer who committed the secret often does not own the service it authenticates. Secrets living in git history, Docker layers, or collaboration tools frequently go undetected by internal scanning entirely, so the 94-day median only reflects the cases where someone knew to look.
Stolen credentials are the dominant breach vector at scale. Verizon's 2024 DBIR attributes 31% of all breaches over the past decade to stolen credentials. Hardcoded secrets are one of the cleanest supply paths for those credentials because they require no social engineering, no phishing, and no vulnerability to exploit beyond knowing where to look.
A secret that is valid, in git history, and not actively monitored is an open door with an unknown number of visitors.
How an Attacker Actually Moves from a Discovered Secret to a Compromised System
Discovery. Attackers scan public GitHub using code-search APIs and purpose-built credential harvesting tools continuously, on no human schedule. Git history is a specific, productive target; deleting a file or a line without rewriting history is one of the most common exploitable gaps teams leave open. Docker Hub and public container registries are equally useful, since image layers preserve the filesystem at build time. Slack workspaces with public link-sharing, Confluence spaces, and Jira tickets indexed by search engines expand the surface further. Generic secrets are harder for defenders to detect, but context tells an attacker exactly what a credential authenticates even when a scanner would not flag it.
Validation. Attackers test credentials before acting. Lightweight API calls verify whether a key is still active; they are fast, low-noise, and typically fall below detection thresholds. For AWS credentials specifically, an attacker checks the IAM permissions associated with an access key pair to understand the blast radius before moving. The 64% still-valid figure translates directly into exploitation opportunity because there is no friction between finding a valid credential and using it.
Exploitation. The impact depends on what was exposed. A database connection string gives direct read/write access to production data: exfiltration, modification, or ransomware staging. Cloud provider credentials enable lateral movement through IAM, data exfiltration from S3 buckets, compute provisioned for cryptomining, or, as documented in real AWS incidents, S3 bucket encryption followed by a ransom demand. Third-party API keys let an attacker impersonate the application itself: a Stripe key enables fraudulent charges, a Twilio key enables SMS phishing at scale, a SendGrid key enables email phishing from the company's own domain. A compromised Artifactory or GitHub Actions token opens the build pipeline to injection, turning credential theft into a supply chain attack. LLM API keys produce immediate financial damage through bill run-up and expose the model's system prompt context.
Persistence and lateral movement. A single valid cloud credential usually yields access to additional secrets stored in environment variables, parameter stores, or connected services. Service-to-service credentials discovered through initial access chain into internal systems that are never exposed to the public internet at all.
What makes this chain repeatable is that exploiting a hardcoded secret requires no novel technique. Discovery is automated, validation is trivial, and exploitation uses the credential exactly as the legitimate application would. Unlike a zero-day, this path does not degrade as defenses improve; it scales with the volume of secrets in circulation.
What a Penetration Test Actually Finds That Automated Scanners Miss
Automated scanners fail on the majority of the exposure by design. Because 58% of all detected secrets are generic secrets with no standardized pattern, rule-based scanners tuned to known formats miss most of the surface before they even start.
A whitebox penetration test reaches what scanners cannot. Secrets deleted from HEAD but still present in the commit graph require active history traversal, not a snapshot scan. Secrets embedded in build artifacts, Docker image layers, and CI/CD logs sit on surfaces that automated tools typically do not scope. Secrets in collaboration tools and documentation are not code, so code-scanning tools do not see them at all.
Beyond surface coverage, there is the question of impact. A tester who finds a valid API key demonstrates what it actually unlocks. Every finding should include a working exploit that proves the blast radius, not just a flag on the key's existence. That distinction matters because not every exposed credential carries equal risk, and prioritizing remediation requires understanding the difference.
The compliance-only failure mode is real and underappreciated. A compliance-scoped penetration test checks for known vulnerability classes against defined targets. It does not, by default, traverse git history or audit CI/CD pipeline configurations. Teams that pass an annual penetration test with no secrets findings are often not getting a clean bill of health; they are getting a narrow-scope assessment that did not look in the right places. Passing that test and concluding the problem is managed is one of the more expensive mistakes a security team can make.
Good scope for a secrets-focused assessment includes git history, build configurations, infrastructure-as-code files, Docker images, and environment variable surfaces. Trace's approach covers exactly this: whitebox access to source code repositories, cloud configurations, and CI/CD pipelines enables the kind of full-surface secrets review that blackbox or compliance-only tests cannot perform, and every finding is proven with a working exploit before it appears in the report.
Remediating Hardcoded Secrets Correctly: What "Fixed" Actually Means
Most teams skip straight to rotation. The correct sequence has three steps, and the order matters.
Revoke first, then investigate. Treat the credential as compromised the moment it is found. Rotation without revoking the original leaves the exposure open during the entire remediation window.
Audit for use before revoking. Check access logs for the compromised credential. Understand whether an unauthorized party has already used it, because the response changes completely depending on that answer.
Rewrite history, or accept the residual risk explicitly. Git history rewriting, using tools like git filter-repo or BFG Repo Cleaner, is the only way to remove a secret from the commit graph. Teams that skip this step leave the secret accessible to anyone with clone access to any historical snapshot. That is a documented, ongoing risk; accept it consciously or eliminate it.
Secrets manager migration is the structural fix that prevents recurrence. AWS Secrets Manager, HashiCorp Vault, and GCP Secret Manager all support runtime injection, which removes the incentive to hardcode at the source. Migration has a real dependency-mapping cost, but that cost is bounded and one-time; the cost of leaving the problem in place is unbounded and recurring.
Pre-commit hooks and CI/CD pipeline gates are the enforcement layer. Tools like git-secrets or GitGuardian's pre-receive hooks intercept secrets before they reach the remote. These gates need to cover generic secrets, not just known patterns, or they catch less than half the problem.
The final piece is detection coverage for surfaces outside the primary codebase: Docker image scanning in your registry, log auditing for pipeline echo behavior, and periodic review of collaboration tool exports. Most organizations have some of these in place; very few have all of them integrated into a single workflow with clear ownership.
"Fixed" means the credential is revoked, the history is clean, the replacement lives in a secrets manager, the gate is in place to catch the next one, and the audit confirmed no unauthorized use occurred during the window between commit and remediation. Everything short of that is partial remediation, which leaves the door open.
