Secrets committed to Git: why deleting them isn’t enough
Once credentials enter Git history, deleting the file doesn’t make them secret again. Rotate first, then clean history and prevent it happening again.
Once credentials enter Git history, deleting the file doesn’t make them secret again. Rotate first, then clean history and prevent it happening again.
Real Composer/vendor credentials were present in repository history. They had to be treated as exposed and rotated — removing them from the latest commit wasn’t enough.
Why deletion isn’t enough
Git keeps every version. Clones, forks, CI caches and backups may already contain the secret.
RELATED GUIDEHow to stop spam and bot attacks on Adobe Commerce Cloud → Protect your site before it’s hackedManaged security with WAF, scanning and unlimited cleanups.Get a free security scan →What to do
- Revoke and rotate the credential immediately
- Check logs for misuse
- Remove it from history (git filter-repo) if needed
- Move secrets to environment variables or a vault
- Enable secret scanning and pre-commit hooks
Common mistakes to avoid
How we help with security
Frequently asked questions
Which secrets leak most?
Composer/Marketplace keys, cloud keys, API tokens and database passwords.
Is a private repo safe?
Safer, but still exposed to everyone with access and any leaks.
Can you audit our repos?
Yes.