What Is GitHub Secret Scanning?
GitHub secret scanning guide starts with a simple idea. Secret scanning is an automatic safety feature that looks for known credential patterns inside your code. It searches for things like AWS access keys, SSH private keys, GitHub personal access tokens, Slack webhooks, and Google API keys. The scanner can either send you an alert or block the code push entirely, depending on your setup.
Public repositories get secret scanning for free. You cannot turn it off. Private repositories need GitHub Advanced Security. However, the cisa github data leak happened because a contractor disabled secret scanning on a public repository. This allowed exposed credentials to stay online for six months without any warning.
For the full story, see our CISA GitHub data leak pillar post.
How Secret Scanning Could Have Stopped the CISA Leak
The cisa github data leak exposed AWS GovCloud keys and plaintext passwords in a public repository. With secret scanning active, GitHub would have done three things:
- Detected the AWS key pattern (
AKIA...) right away. - Blocked the code push or sent an instant alert.
- Notified GitHub’s security team about the leaked keys.
Because the contractor turned off secret scanning, none of these protections worked. The keys stayed exposed for half a year. This shows why disabling secret scanning is a huge mistake.
For more on the AWS GovCloud keys involved, see our AWS GovCloud explained guide.
How GitHub Secret Scanning Works Under the Hood
Secret scanning uses several methods to find credentials. Here is what happens behind the scenes.
Pattern matching is the first method. GitHub keeps a list of regular expressions for known credential formats. For example, AWS access keys always follow the pattern AKIA[0-9A-Z]{16}. When a commit contains a string that matches this pattern, the scanner flags it.
Partner patterns come next. GitHub works directly with service providers like AWS, Google, and Slack. If a detected string matches a live credential, GitHub can ask the provider to revoke it automatically.
Heuristic detection looks for credentials without fixed patterns. It checks for randomness (entropy) and context. For example, a file named secrets.csv with high‑entropy text triggers a warning.
Full historical scans happen when you enable secret scanning on an existing repo. GitHub scans the entire commit history, not just new pushes. This finds old credentials that were never caught.
For a practical guide to turning on these features, see the “How to Turn On” section below.
Types of Credentials That Secret Scanning Detects
GitHub secret scanning recognizes over 200 credential types. Here are the most common ones:
| Credential Type | Example Pattern | Risk Level |
|---|---|---|
| AWS Access Key | AKIA... (20 characters) | Critical |
| SSH Private Key | -----BEGIN OPENSSH PRIVATE KEY----- | Critical |
| GitHub Personal Access Token | ghp_... (36+ characters) | High |
| Slack Webhook URL | https://hooks.slack.com/services/... | High |
| Google API Key | AIza... (39 characters) | High |
| Stripe Secret Key | sk_live_... (24+ characters) | Critical |
| Twilio Account SID | AC... (34 characters) | Medium |
| Generic passwords | (detected by context and entropy) | Varies |
The cisa github data leak included AWS keys (pattern match) and plaintext passwords (heuristic detection). Both should have triggered alerts.
Why Disabling Secret Scanning Is So Dangerous
Some developers turn off secret scanning to avoid delays. They may find false positives annoying. But the risks are much bigger than the inconvenience.
| Risk | Consequence |
|---|---|
| Accidental credential exposure | Attackers can scrape secrets from public repos automatically. |
| Compliance failures | Frameworks like SOC2 and FedRAMP require secret detection. |
| Supply chain attacks | Leaked Artifactory credentials can lead to backdoored software. |
| Reputation damage | Public leaks destroy trust in your organization. |
| Legal trouble | Exposed customer data can lead to fines and lawsuits. |
In the cisa github data leak, the contractor turned off secret scanning to avoid blocking his commits. This one choice turned a small mistake into a six‑month national security risk.
For more on supply chain risks, see our Artifactory supply chain security guide.
How to Turn On Secret Scanning for Your Repos
For public repositories: Secret scanning is already on. You cannot disable it. Good.
For private repositories (need GitHub Advanced Security):
- Go to your repository on GitHub.
- Click Settings > Code security and analysis.
- Find Secret scanning and click Enable.
- Also turn on Push protection (see next section).
For organizations (enable many repos at once):
- Go to your organization’s Settings > Code security and analysis.
- Enable secret scanning for all repositories at the same time.
- Set a policy that stops members from turning it off.
Push Protection: A Stronger Safety Net
Push protection is an extra feature that blocks any code push containing a detected credential. Instead of alerting you after the fact, push protection stops the leak before it happens.
How push protection works:
- A developer tries to push a commit with a credential.
- GitHub scans the commit in real time.
- If the scanner finds a credential, GitHub rejects the push.
- The developer sees an error message with the file name.
- The developer must remove the credential before pushing again.
Why you should enable push protection:
- It stops accidental leaks completely, not just warns you.
- It teaches developers about safe practices.
- It reduces the workload on security teams.
In the cisa github data leak, push protection would have blocked the original push. The contractor would have had to remove the credentials or store them properly.
For more on stopping risky developer habits, see our shadow sync developer risk guide.
What to Do When Secret Scanning Finds a Credential
When GitHub sends you a secret scanning alert, act fast. Follow these steps:
- Look at the alert – Go to the repository’s Security tab and open the alert.
- Identify the exposed credential – Note what type it is (AWS key, GitHub token, etc.).
- Rotate the credential – Create a new key or token. Update any apps that use the old one.
- Remove the credential from the repo – Delete the file or line that contains the secret.
- Push the fix – Commit the removal and push it. Push protection will not block removal.
- Close the alert – Mark it as resolved in GitHub.
- Learn from the mistake – Figure out how the credential got there. Improve your training or tools.
Do not just delete the file without rotating the credential. Attackers may have already copied it. Rotation makes the old key useless.
For a full incident response plan, see our incident response for leaked credentials.
Simple Steps to Prevent Credential Leaks
Follow these best practices to protect your organization:
| Practice | Why It Helps |
|---|---|
| Use a secrets manager | No more hard‑coded credentials in code. |
| Rotate secrets automatically | Shortens the window of exposure. |
| Train developers on security | Reduces human errors. |
| Add pre‑commit hooks | Scans for secrets before git creates a commit. |
| Audit repos regularly | Finds old leaks that secret scanning might miss. |
| Use short‑lived credentials | Leaked keys stop working after a short time. |
| Never store secrets in environment variables | They can appear in logs or debug output. |
For developer‑specific password rules, see our password hygiene for developers.
Frequently Asked Questions
Q: Can secret scanning find credentials from years ago?
Yes. When you turn on secret scanning for an existing repository, it scans the full commit history. You will get alerts for any old credentials.
Q: Does secret scanning work on forks?
Yes, but alerts go to the fork owner, not the original repository. This matters if someone forks a repo that contains secrets.
Q: What if I get a false positive alert?
You can mark it as false positive. But always check carefully. A string that looks like a test could actually be a live credential.
Q: Can I turn off secret scanning for a single file?
No. GitHub does not allow this for security reasons. If you have a known false pattern, you can use advanced git settings, but it is risky.
Q: How does GitHub work with credential providers?
GitHub shares detected credentials with providers like AWS, Google, and Slack. Those providers may revoke the credential automatically, even before you see the alert.
Q: Why did the CISA leak not trigger secret scanning?
The contractor disabled secret scanning on the public repository. There are ways to bypass the default settings, like using git push --no-verify to skip pre‑receive hooks.
Q: Is secret scanning enough by itself?
No. Use it as one layer. Combine it with pre‑commit hooks, a secrets manager, and regular audits.
