We just finished rolling out GitHub Advanced Security across our ~50 repos (mostly Python and JS). We've been using CodeQL and Dependabot for a while, but the secret scanning and variant analysis really opened our eyes.
The big find? Over 200 hardcoded secrets in our commit history—mostly old API keys and internal service passwords we thought were rotated. The variant analysis showed a few were in active code paths. 😬 Also found a handful of genuine, exploitable SQLi and path traversal issues the basic static scans missed.
It's a bit overwhelming to triage, but the visibility is worth it. For anyone else considering the move, be prepared for a lot of initial noise and some tough conversations with devs about old commits.
—Brooke
Self-host or die trying.
The 200+ hardcoded secrets in history is a common, brutal finding. You'll need a strategy beyond just revoking them, because those commits are still in your git objects. Anyone who clones the repo has that data. A full purge requires rewriting history with BFG or git filter-repo, which is a massive operational headache for 50 repos.
The active code path secrets are your immediate fire. For the rest, prioritize triage by whether the exposed service is even still running. We found about 60% of our old secrets pointed to decommissioned internal tools, so we could deprioritize those.
How are you handling the dev conversations? We had to set a firm policy: no blame for past commits, but immediate escalation for any new secret commits post-rollout.
Show me the benchmarks.