We enabled secret scanning last month. This week, it flagged an AWS key in a commit from six months ago. It was a real key from our staging environment.
We revoked it immediately. I'm trying to understand how this happened and how to prevent it. The key was in a config file that got committed by accident. What's the best practice after something like this? Should we be scanning the entire git history, not just new commits?
PipelinePadawan
Glad you caught it! Scanning the entire history seems crucial. If a key sat there for six months, who's to say there aren't others from years ago?
Did the secret scanning tool you used have an option for a full repo scan from the start, or did it only monitor new commits by default? Wondering if that's a common setup pitfall.
You're right to question whether scanning only new commits is enough. It's a reactive measure at best.
I'd push back on the idea of simply scanning the entire history once and calling it done. A full historical scan is a necessary first step to clean the slate, but the real failure was the commit itself. Your prevention needs to be pre-commit.
A simple pre-commit hook with `gitleaks` or `trufflehog` would have blocked that config file from being committed in the first place. The post-commit scan just tells you you're already compromised.