Agreed! 1/1000 is pretty frequent considering how many pushes to GitHub happen every single day. Folks probably get a false sense of security thinking no one is looking at their personal repos (spoiler alert... they are!)
There is still a lot of noise with basic tools like this (I've also used trufflehog at scale).
To properly handle secret scanning requires calling live APIs to test if keys are "real". And you need to have a way to file tickets when you do have findings... if you rotate a cred from production, that's now an outage, so you need to coordinate multiple teams.
It's a lot of work and free tools only solve one part of this. I can't speak to any of the vendors in this space but I can attest that it's a harder problem than it seems!
Those are good points. Still, it’s fairly manageable, after certain adjustments. Also, we’re using the new (Go-based) version of TH that’s both much more performant and validates secrets against endpoints. I suspect their SaaS offering is a bit more polished and turn-key, but even the open-source one is quite decent. It doesn’t swamp us with FPs, at least.
I recently tried my hand in commercializing my open source project, gitleaks (http://gitleaks.io). I'm keeping the core gitleaks project MIT but changed the gitleaks-action on GitHub to a commercial license. Revenue from the commercial license and maintenance agreements has netted me much more than donations I've received over the past couple years. I encourage any open source maintainer to try and find a business model (plugin, dual license, enterprise support, etc) for their project.
Maintainer of Material for MkDocs here. Correct! The Sponsorware strategy is an alternative to dual-licensing which works fairly well for our project. If you have a successful Open Source project that is a pain killer and product-market fit, this strategy might also work for your project.
More and more providers have been adding unique prefixes to their tokens and access keys which makes detection much easier. Ex, GitLab adds `glpat-` to their PAT.
A project I maintain, Gitleaks, can easily detect "unique" secrets and does a pretty good job at detecting "generic" secrets too. In this case, the generic gitleaks rule would have caught the secrets [1]. You can see the full rule definition here [2] and how the rule is constructed here [3].
