PingCAP’s breach and the case for keeping secrets out of Git

A deployment script needs a cloud credential. Someone puts it in a configuration file, commits it to a private repository and gets the job working.

The awkward bit comes later. That repository now contains both the instructions for reaching a system and a credential that may let somebody in. Every clone, build runner and backup holding that commit becomes another place to protect.

The PingCAP incident is a reason to look at that workflow in your own environment. Keeping credentials out of source control removes a route by which a code leak can become infrastructure access. It also makes ownership, replacement and access review easier to manage.

What PingCAP has confirmed

PingCAP’s incident report says stolen service-account credentials enabled internal access and copying between 9 September and 7 October 2026. Exposed material included source code, customer account information, SQL-editor text and commercial records. It reports no evidence that data stored in TiDB was affected; investigation continues.

The circulating 10.6 TB total is an attacker claim, rather than a verified impact figure. Reporting on the claim makes that distinction. PingCAP’s report does not establish repository-stored GCP/Azure credentials as the initial entry route, or confirm the six-hour export schedule, 88 exports or “zero alerts” account.

That leaves a useful engineering question: if someone copied one of your private repositories today, what usable credentials would they get?

A private repository still needs a credential boundary

Code needs to travel. Engineers clone it, CI systems check it out, support teams inspect it and backups preserve it. A credential embedded in that code travels with it.

Google’s service-account guidance explicitly advises against committing keys to repositories. It also explains why deleting the file afterwards is insufficient: history and copies can retain the credential.

For your own review, follow one deployment job from checkout to production. Identify where it gets its credentials, which identity those credentials represent and what that identity can actually do. Include examples, old branches and build output in the search.

If you find a live credential, removing the line is only part of the repair. Revoke or replace it at the issuing service, update legitimate consumers and review its use. A clean current branch does not invalidate yesterday’s key.

Remove the reusable key where you can

Before choosing where to store a cloud key, check whether the workload needs one.

Google recommends alternatives to user-managed service-account keys, including attached identities and workload identity federation. Azure managed identities let supported workloads obtain tokens for services using Microsoft Entra authentication without developers maintaining a reusable application secret.

Those options still need carefully scoped permissions and protected workloads. But they remove a credential file that an engineer would otherwise have to store, distribute and rotate.

Mixed estates also contain supplier integrations, older applications and deployment jobs that still require a password, configuration secret or private key. Those credentials need a controlled home and a defined way to reach the process using them.

Where CertLocker changes the workflow

CertLocker secrets management keeps credentials and configuration secrets in a managed inventory, with group access, version history and audit events. Scoped secret-access tokens let a consumer retrieve the resources it has been permitted to use, with expiry and revocation controls.

Consider a deployment job that still needs a reusable credential. The intended workflow is:

1. Store the credential outside Git. Give it an owner and assign the appropriate group access in CertLocker. Keep a non-secret reference in the deployment configuration.
2. Configure the job’s access separately. Use a scoped token for the required secret and a suitable lifetime. Provision that token through the runner’s protected credential mechanism. Putting the token in Git would recreate the exposure.
3. Retrieve the value when the job needs it. Keep it out of command traces, logs and build artifacts. Protect the runner that receives it.
4. Keep the access and change records. Use secret-fetch audit events and version history to review retrievals and changes through CertLocker.
5. Replace the underlying credential when required. Update the issuing service, move consumers to the replacement and invalidate the old value. Saving a new secret version is a record of a change, not proof that an old cloud key has stopped working.

With that workflow in place, copying the repository would not reveal the credential, provided it and the retrieval token had never been committed. That is the specific exposure CertLocker can help remove.

Once a process receives a raw credential, that process can still leak or misuse it. Revoking its CertLocker token stops subsequent retrieval through that token; it does not revoke a cloud credential the process already copied. The issuing service remains responsible for that credential’s validity and permissions.

Check what happens after authentication

A secret-fetch record answers who retrieved a value through CertLocker. Your cloud audit records answer what happened when a cloud identity used it. An incident review needs both views.

For the deployment job above, I would review whether its cloud identity can read unrelated storage, change permissions or create a replication feed. Where those capabilities exist, they deserve a named owner and a clear reason. I would also test whether an unexpected export reaches someone who can investigate it.

Repository scanning, cloud IAM, workload protection and export monitoring remain separate controls. Keeping secrets out of Git addresses one important entry path; it does not establish that a particular incident would have been prevented.

A practical next step

For affected TiDB Cloud customers, PingCAP’s customer-action notice advises replacing active management API keys and watching for targeted phishing. If misuse is suspected, it says to revoke immediately rather than wait for a replacement.

For your own team, pick one production deployment job. Establish where its credential lives, who can retrieve it, what it can access and how you would invalidate every usable copy. That gives you something concrete to improve this week.

If you want to work through that job together, arrange a face-to-face meeting or video call. We can demonstrate the hosted CertLocker secret-access, version-history and audit workflow against the way your team works today.

Incident sources checked on 22 October 2026.