Managing Secrets and Sensitive Files in Repositories

One of the most common and most damaging mistakes in software development is accidentally committing sensitive information to a Git repository.

API keys, database passwords, AWS credentials, private certificates, when these end up in a repository, especially a public one, the consequences can be severe.

Accounts get compromised, data gets stolen, and cloud bills spike overnight because someone found your AWS keys and started mining cryptocurrency on your account.

This is not a rare edge case. It happens to experienced developers at large companies regularly. The good news is that it is entirely preventable.

What Counts as a Secret?

Before you can protect sensitive information, you need to know what qualifies as sensitive. The rule is simple:

If this information gives someone access to a system, account, or resource — it is a secret and must never be committed to a repository.

Common secrets that must never be in code:

Credentials and Keys

1. AWS Access Key ID and Secret Access Key

2. Database usernames and passwords

3. SSH private keys

4. API keys for third-party services — Stripe, Twilio, SendGrid, Google Maps

5. OAuth client secrets

6. JWT signing secrets

Certificates and Cryptographic Material

1. TLS/SSL private keys and certificates

2. PGP private keys

3. Any .pem, .key, .p12, or .pfx files

Configuration with Embedded Secrets

1. .env files containing real values

2. application.properties or config.yaml files with hardcoded passwords

3. Terraform .tfvars files with real credentials

4. Kubernetes secret manifests with base64-encoded values

Infrastructure Details That Aid Attackers

1. Internal IP addresses and hostnames of production systems.

2. Database connection strings pointing to production.

3. Account IDs combined with role names in sensitive contexts.

Why This is a Bigger Problem Than It Seems

Git stores the complete history of every change ever made. When you commit a file containing a secret and then delete it in the next commit, the secret still exists in the repository history.

Anyone who clones the repository can run git log and git show to retrieve the original file with the secret intact.

This is even worse for public repositories. Within minutes of a secret being pushed to a public GitHub repository, automated bots scan for exposed credentials.

AWS keys pushed to a public repository have been found and exploited within seconds — not minutes, not hours. Seconds.

Even for private repositories, the risk does not go away. If the repository is ever made public, if an employee's account is compromised, or if someone with access leaves the organisation — the secret is still there in the history.

The only correct response when a secret is committed is to revoke and rotate it immediately — not just delete it from the repository.