Repo Security Governance

Your private repo isn't secure. It's just less exposed.

Most founders and product managers treat their GitHub repository as a place to store code. But the moment a product grows — clients, payments, contracts, credentials — the repo stops being just code. It becomes operational data.

And there's a Git behaviour most people overlook: deleting a file doesn't remove it from history.

An IBAN in a markdown file. An API key in a .env committed by mistake. Client data in an email template. You delete it, push, and assume it's gone. It isn't — it remains in the history and can be recovered by anyone with access to the repository.

This isn't a scale problem. It's a governance problem.

Mature solutions have existed for years. Repository-level encryption allows certain files to remain readable locally while being encrypted on the remote.

Tools like git-crypt keep the Git workflow practically unchanged after setup. It takes less time to configure than to deal with the consequences of a leak.

Three principles I apply across all my repositories:

Block at the gate — pre-commit hooks, secret scanning and push protection to reduce the likelihood of credentials entering the history

What shouldn't live in the repo — raw credentials belong in a secret manager or password vault, never in the code

What must live in the repo — if it has to be there, it has to be encrypted. No exceptions — not "it's just temporary", not "the repo is private"

All it takes is one collaborator, one CI/CD integration, or one platform migration to realise that "private" doesn't mean "protected".

Governance isn't overhead. It's what separates a side project from a product someone trusts with their data.

Sources

• git-crypt — transparent file encryption in Git: https://github.com/AGWA/git-crypt
• GitHub secret scanning and push protection: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning
• Git history rewriting (git-filter-repo): https://github.com/newren/git-filter-repo