GitHub Secret Leak: Why Rotation Matters

A GitHub commit can expose an API key in seconds. Even if you notice the mistake and delete the key a few minutes later, that does not make the secret safe.
The key may still exist in Git history, forks, caches, logs, or other copies. More importantly, automated secret-scanning bots can detect newly exposed credentials very quickly.
The correct response is simple: treat an exposed secret as compromised and rotate it immediately.

Why Deleting the API Key Does Not Fix the Problem​

Suppose you accidentally commit an AWS access key like this:

AWS_ACCESS_KEY_ID=AKIAxxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=your-secret-key

You notice the mistake, remove the credentials, and make another commit.
The current version of the file may now be clean, but the original commit can still contain the secret.
Git is designed to preserve project history. Removing a value from the latest version does not automatically remove it from previous commits.
Someone who has access to the repository history may still be able to find the old value.
More importantly, deleting the secret from Git does not revoke the credential itself.
If somebody already copied the key, removing it from the repository cannot undo that exposure.

---

How Quickly Can Exposed Secrets Be Detected?​

Public GitHub repositories are continuously monitored by automated systems that look for credentials and other sensitive information.
AWS credentials, Stripe keys, database passwords, cloud tokens, and API keys can match recognizable patterns or be detected by specialized secret-scanning systems.
That means the time between publishing a secret and its discovery can be very short.
You should never assume:
"I noticed it after five minutes, so nobody could have seen it."
There is no safe waiting period.
Once a secret has been pushed to a public repository, treat it as compromised.

---

What Can Happen After a Secret Is Exposed?​

The impact depends on what the credential can access.
For example, an exposed cloud credential could potentially allow an attacker to:

• Create or modify cloud resources.
• Access storage or databases.
• Run compute workloads.
• Access application services.
• Generate unexpected usage charges.
• Access data that the credential is authorized to read.

An exposed payment or AI API key can also result in unauthorized API usage and unexpected charges.
A database password may provide direct access to sensitive application data.
The important point is that the financial and security impact comes from the permissions attached to the credential, not simply from the fact that the key appears in Git.

---

The Right Way to Handle an Exposed Secret​

If you accidentally commit a secret, do not start by trying to clean the Git history.
Start by invalidating the credential.
A practical response is:

1. Revoke or rotate the exposed credential immediately.
2. Check whether it was used before it was revoked.
3. Review relevant logs, billing information, and audit events.
4. Remove the secret from the working files.
5. Remove it from Git history if necessary.
6. Search the repository for other exposed secrets.
7. Create a new credential with only the permissions the application actually needs.

The order matters.
Rotating the credential protects you from continued use of the exposed value.
Cleaning Git history is useful, but it should not be treated as a replacement for credential rotation.

---

What About the Git History?​

If a secret was committed, removing it from the latest version is often not enough.
You may need to remove the secret from repository history, especially if the repository is public or the repository history is accessible to people who should not have seen it.
However, history rewriting has consequences.
It can change commit IDs and require coordination with anyone who has cloned the repository.
For an important repository, make sure you understand the impact before rewriting history.
And remember:
History rewriting does not make an already exposed credential safe.
If someone copied the secret before the history was cleaned, they can still use the original value until it is revoked or rotated.

---

How to Prevent Secrets From Entering Git​

The best solution is to prevent credentials from being committed in the first place.
Instead of putting a secret directly in source code, load it from an environment variable or a dedicated secret-management system.
For example:

import os

api_key = os.environ["API_KEY"]

Your local environment can provide the value without putting it directly in the source code.
If you use a .env file for local development, make sure it is excluded from Git.
For example:

.env
.env.*
!.env.example

You can keep a safe example configuration in the repository:

API_KEY=
DATABASE_URL=

The example file shows developers which variables are required without containing the real credentials.

---

Use Secret Scanning and Push Protection​

Prevention is much better than discovering a leaked credential after deployment.
GitHub provides security features that can detect certain secrets and, where supported, prevent pushes containing detected credentials.
Enable Secret Scanning and Push Protection for repositories where these features are available.
They can add an important safety layer before a secret reaches the repository.
You should still use local checks and developer tooling because no single secret-detection system catches everything.

---

Scan Existing Git History​

If you are worried that your repository already contains exposed credentials, scan the history rather than checking only the latest files.
Tools such as TruffleHog and GitGuardian can help identify secrets in repositories and their history.
A history scan is particularly useful for older projects where credentials may have been committed years ago.
For a public repository, also remember that removing a secret today does not prove that nobody accessed or copied it previously.

---

Do Not Hardcode Secrets in Application Code​

Avoid patterns like:

const apiKey = "sk-example-secret";

Even private repositories can be copied, forked, mirrored, backed up, or accessed by people who should not have the credential.
Instead, load the value from a secure configuration source:

const apiKey = process.env.API_KEY;

For production systems, a dedicated secret manager is often preferable to manually managing long-lived credentials in environment files.
The exact solution depends on your platform and deployment architecture.

---

Use Short-Lived and Least-Privilege Credentials​

Preventing leaks is only part of the problem.
A credential should also have the minimum permissions and lifetime required for its job.
For example, an application that only needs to read objects from a specific storage location should not use a credential with broad administrative permissions across an entire cloud account.
This limits the damage if the credential is accidentally exposed.
Good secret management usually combines:

• Least privilege - give the credential only the permissions it needs.
• Short lifetimes - avoid long-lived credentials when possible.
• Rotation - replace credentials regularly or after exposure.
• Monitoring - detect unusual or unauthorized usage.
• Secret scanning - catch accidental commits before they spread.

---

What If You Already Committed a Secret?​

If this just happened, do not panic and do not spend the first few minutes trying to rewrite Git history.
Do this first:

1. Revoke or rotate the credential.
2. Check audit logs and usage records.
3. Look for unexpected resources, API calls, or charges.
4. Remove the secret from the repository.
5. Scan the Git history for additional secrets.
6. Clean the history if appropriate.
7. Replace the credential everywhere the application uses it.
8. Add preventive controls so the same secret cannot be committed again.

For cloud credentials, also check whether the exposed identity created resources or performed actions you do not recognize.
If there is evidence of unauthorized activity, preserve the relevant logs before they expire.

---

The Most Important Rule​

If a secret reaches a public Git repository, assume it has been seen.
It does not matter whether you deleted it after 30 seconds, five minutes, or 20 minutes.
It does not matter whether the secret is still visible in the current version.
It does not matter whether the repository is small.
The correct assumption is that the credential is compromised until you revoke or rotate it.
Git history cleanup helps reduce future exposure, while credential rotation prevents the leaked value from continuing to work.

---

Frequently Asked Questions​

-----------------

Does deleting an API key from GitHub make it safe?​

No. The old value may remain in Git history, forks, clones, caches, or other copies. If the credential was exposed, revoke or rotate it immediately.

Should I delete the Git commit that contains the secret?​

You may need to remove the secret from Git history, especially for a public repository, but history cleanup does not replace credential rotation.

Is putting an API key in a private GitHub repository safe?​

It is safer than putting it in a public repository, but it is still not a good way to manage secrets. Use environment variables or a dedicated secret-management system instead.

What should I do if an AWS key was accidentally pushed?​

Immediately deactivate or rotate the exposed key, then review AWS activity and billing for unauthorized usage. After that, remove the credential from the repository and investigate the Git history.

Can GitHub Secret Scanning prevent secret leaks?​

GitHub's secret-scanning and push-protection features can detect or block certain supported secrets, but they should be considered an additional layer of protection rather than a guarantee that every secret will be detected.

Should I commit a​

Generally, no. Keep real credentials out of the repository and add .env to .gitignore. A safe .env.example file can document the required variables without containing real secrets.