Truffle Security is coordinating with API-key issuers to revoke credentials found in public code, packages, container images and datasets. Its November 4 announcement by Luke Marshall and Dylan Ayrey describes two routes: revocation through an issuer-provided endpoint, or delivery to the issuer for action within 14 days.

Evidence status: vendor-reported credential testing and a new response program. This is evidence of exposed working credentials, not a count of breached organizations or completed attacks. Bill Toulas’s November 5 BleepingComputer report covers the announcement.

A key stays dangerous after its public copy disappears

An API key lets software authenticate to a service. Anyone who copies an exposed key may inherit its permissions until it expires or is disabled. Removing a repository file cannot invalidate copies already taken from its history, an image or a dataset.

Truffle says it has found 1.4 million leaked keys that passed its tests since 2022, including more than one million in the past year. Those are its accumulated detections. They do not establish how many organizations were affected or that every previously tested key remains usable today.

The company reports that 81% of 21,981 keys it previously reported from GitLab and Bitbucket still worked six months later. That measured cohort supports concern about notification without follow-through. It cannot establish a universal response rate for all developers.

The relevant exposure is a published credential that still authenticates and retains useful permissions. Its impact depends on scope: a narrow service token and a broadly privileged cloud key carry different risks.

Issuer action reaches owners who miss the warning

The program says 16 issuers have joined, including Hugging Face, Notion, Vercel, Resend, RubyGems and Twilio. Truffle verifies a key before sending it to its issuer. In the issuer-handled route, the issuer must revoke within 14 days or explain why it cannot. That is a program commitment, not guaranteed immediate containment of every leaked key.

The approach extends beyond repository scanning. Truffle says three quarters of the Resend keys it delivered came from Docker images, while more than half of the Vercel keys in its analysis came from Hugging Face datasets. Those are service-specific observations, not the distribution of all leaks.

Issuer-side disabling has an established precedent. Google announced automatic disabling of detected exposed service-account keys beginning June 16, 2024, with an opt-out. Google also warned that disabling a production key can interrupt workloads.

Replace access and investigate its use

For developers and operators, a leak should trigger a managed response:

  • Revoke the exposed credential through its issuer. Do not wait for a research program or assume deleting the public copy is enough.
  • Identify dependent workloads and deploy a replacement through the normal secure process. Coordinate continuity while prioritizing containment of active abuse.
  • Review the key’s permissions and available access logs. Investigate what it could reach and whether its use changed after exposure.
  • Check published artifacts as well as current source. Images, package contents, build output and retained histories can contain additional copies or other credentials.
  • Reduce future standing access. Prefer short-lived workload identities where supported, and give remaining keys separate owners and minimal permissions.

A replacement plan makes issuer-side revocation survivable. A confirmed successful workload restart does not answer whether someone used the old key before it was disabled.

Caveat: Truffle sells secrets-security products and supplies the detection totals; the announcement does not independently establish completed revocation of all 1.4 million detections.