Secret Scanning: Don't Push Keys to GitHub

This article has three layers:

1. Layer 1: The Intuition: Leaving your keys on a public bulletin board
2. Layer 2: Real-World Use: Uber and Toyota incidents, GitHub push protection
3. Layer 3: Principles and engineering key points: How to identify keys, the three lines of defense, and post-leak procedures

Layer 1: The Intuition

1.1 Leaving your keys on a public bulletin board

You post a photo of your house keys on a public bulletin board in your residential community, realize your mistake a few minutes later, and quickly tear it down.

However:

• Someone has already taken a photo;
• The bulletin board has a "history" feature, allowing anyone to view the version before you tore it down.

At this point, the only solution is to change the locks. A public Git repository is exactly like this bulletin board.

1.2 Why people keep making this mistake

• Writing them temporarily in the code for debugging and forgetting to remove them;
• Committing .env files (failing to add them to .gitignore);
• Changing a private repository to public without realizing there are keys in the history;
• AI programming tools hardcoding keys to make the code run (see "Credential Leaks and Context Windows").

Layer 2: Real-World Use

• Uber (2016): An attacker gained access to a private code repository used by Uber engineers, found AWS access keys, and subsequently downloaded data for approximately 57 million users and drivers from cloud storage. Uber also paid the attacker $100,000 to keep the incident quiet, which later resulted in regulatory penalties and the indictment of their former Chief Security Officer.
• Toyota (2022): A contractor accidentally published source code containing access keys to a public repository; it was discovered nearly five years later, potentially involving approximately 300,000 customer email records.
• Automated Exploitation: Multiple security studies have placed "decoy" cloud keys in public repositories and observed that they are typically attempted for use within minutes to hours.
• GitHub Push Protection: GitHub partners with many service providers to identify hundreds of key formats; starting in 2024, push protection is enabled by default for public repositories. If a push contains a key in a known format, it will be directly blocked. Many service providers automatically revoke the key upon receiving a leak notification from GitHub.

Layer 3: Principles and Engineering

3.1 How to identify keys

Service providers design prefixed key formats specifically to make scanning more accurate.

3.2 Three lines of defense

Combined with source-level measures:

• .gitignore contains .env, key files, and cloud credential directories;
• Use keystores or secret management tools for local development instead of plaintext files (see "Least Privilege and Key Management");
• Never put any secrets in frontend code; frontend code is visible to everyone.

3.3 Post-leak response workflow

Key points:

1. Rotation is the first step, and the only reliable step. Deleting commits, rewriting history, or making the repository private is not enough: the key may have already been copied, and it may still exist in forks, caches, or mirrors;
2. Rewriting Git history (e.g., using git filter-repo) can reduce the chance of it being discovered again in the future, but only after it has been rotated;
3. Check the service provider's access logs to see if there were any anomalous calls within the leak window;
4. Conduct a post-mortem and patch the missing defenses (see "Incident Response and Post-mortems").

3.4 Minimizing the impact of a leak

Even with best practices, leaks can happen. Preparing these in advance can significantly reduce the impact:

• Keys should have least privilege and short expiration (see "Least Privilege and Key Management");
• Set usage limits and budget alerts on cloud services (see "Rate Limiting and Abuse Prevention");
• Use keyless solutions like OIDC whenever possible instead of long-lived keys (see "CI/CD Pipeline Security").

Summary