Truffle Security published research showing a stubborn weakness in modern software security: exposed credentials are still being found in public code repositories, and many of them continue to authenticate long after they should have been killed.

The headline number is large, but the operational lesson is more important. Truffle scanned a public-code corpus built from 224 million GitHub repositories and reported 543,699 unique credentials that still authenticated when tested in July 2026. The median live credential had reportedly been exposed for more than two years.

For SMBs and government contractors, this is not just a developer hygiene story. Exposed secrets are identity risk, cloud risk, CI/CD risk, vendor risk, and incident-response risk all at once. If a key is still valid, removing it from a repository does not remove the access.

What Truffle Security found

Truffle Security analyzed a snapshot of public GitHub repositories assembled for AI training data and tested candidate credentials against the services that issued them. The company reported more than half a million live credentials, with exposures spanning cloud service accounts, database connection strings, API keys, developer tokens, and other secrets.

The research also highlights why prevention alone is not enough. GitHub push protection can stop recognized secret patterns before they land in public code, and Truffle says that control reduced the rate for credential types it covers. But many exposed credentials were already public before protections were enabled, and many credential formats are not blocked by default.

The key defensive takeaway is simple: secret scanning is not complete remediation. Detection starts the clock. Verified revocation stops it.

Why live exposed credentials are so dangerous

A public credential changes the attacker’s job. Instead of exploiting a vulnerability, guessing a password, or phishing a user, the attacker may be able to authenticate directly into a service, pipeline, database, SaaS tool, cloud account, or internal system.

That matters because many leaked secrets belong to non-human identities: service accounts, workloads, automation jobs, deployment systems, monitoring tools, and AI or SaaS integrations. These identities often have broad access, weak ownership, long lifetimes, and poor visibility compared with human user accounts.

For a small team, the worst-case failure mode is familiar: a scanner finds a secret, a ticket gets opened, someone deletes the file or rewrites history, and the organization assumes the issue is fixed. If the credential still authenticates, the risk is still live.

Where SMB and gov-contractor teams should focus

Government contractors, professional services firms, MSPs, and small software teams often rely on GitHub, cloud consoles, CI/CD platforms, collaboration tools, managed databases, and outsourced development. That creates a large secret footprint even without a large security team.

The practical goal is not to build a perfect enterprise secrets program overnight. The goal is to close the gap between discovery and confirmed revocation.

  • Inventory non-human identities. Track service accounts, API keys, CI/CD tokens, cloud access keys, database users, webhook secrets, and SaaS integration credentials.
  • Verify whether findings still work. Prioritize active credentials over dead examples or placeholder values. A live credential is an access path.
  • Map the blast radius. For every live secret, identify the issuing system, owner, permissions, reachable data, allowed source networks, and downstream dependencies.
  • Revoke first, then clean history. Removing a secret from Git history may reduce future discovery, but revocation is what removes access.
  • Confirm revocation. Re-test or otherwise validate that the exposed credential no longer authenticates before closing the ticket.
  • Move toward short-lived credentials. Prefer workload identity federation, managed identities, OIDC-based CI/CD access, and temporary tokens over static long-lived keys.
  • Turn on push protection where available. Default controls help, but also enable generic secret detection where appropriate and tune it to reduce bypasses.
  • Monitor for use after exposure. Review cloud audit logs, database logs, SaaS access logs, and CI/CD activity for suspicious use of the exposed identity.

Incident response checklist

If your organization finds a real secret in a public repository, treat it like an access incident, not a code cleanup task.

  1. Preserve context. Capture the repository, path, commit or file timestamp, exposed credential type, and discovery source.
  2. Identify the issuer. Determine which cloud, SaaS, database, CI/CD, or internal system created the credential.
  3. Check whether it is active. Use safe verification methods or provider consoles to determine whether the key can still authenticate.
  4. Revoke or rotate immediately. Do not wait for code cleanup before killing the access.
  5. Hunt for abuse. Review recent activity from that identity, especially unusual source IPs, data access, privilege changes, deployments, token creation, or lateral movement.
  6. Replace with least privilege. Reissue only the minimum permission needed, ideally with shorter lifetime and better logging.
  7. Close with evidence. Document the revocation time, validation result, blast-radius review, and follow-up control changes.

Bulwark Black assessment

Exposed credentials are one of the places where security teams can fool themselves with good-looking process. A finding exists, a ticket exists, a pull request exists, and a repository looks clean. But attackers do not care whether the secret was removed from the file. They care whether the credential still works.

The mature control is a lifecycle: prevent leaks where possible, detect what gets through, verify whether it is active, understand what it reaches, revoke the access, and confirm the revocation. Anything short of that leaves too much risk sitting in the gap between “found” and “fixed.”

For SMBs and government contractors, this belongs in the same priority bucket as MFA, endpoint visibility, backup testing, and patch management. A single forgotten CI/CD token, cloud service account, or database URI can bypass a lot of expensive security tooling.

Original source: Truffle Security — GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them..

Additional context: Truffle Security — Why exposed credentials stay live for years.