[greysteil]

I worked on this before leaving GitHub a couple of months ago. It’s awesome. This release is a repo-level setting, which is nice, but it will be even more useful when the team releases a user-level setting in June/July. That will allow you to configure GitHub to (softly) prevent you from pushing any easily identifiable secrets to any public repo. The plan is for it to be on by default.

For context, about 200 new GitHub personal access tokens (PATs) are exposed in public repos every day, together with many more tokens from other providers. GitHub automatically revokes the PATs it finds, and notifies many partners if/when keys to their services are found, but we always felt it would be better to prevent the leaks from happening in the first place.

[igetspam]

How does it compare to Trufflehog?

[greysteil]

Same goal, different strengths / weaknesses.

GitHub has really focussed on preventing credential leaks. It's particularly good at scanning for highly identifiable patterns and preventing pushes that include them. That makes sense for GitHub: they're in the best position to prevent leaks (by rolling out push protection to all users) and they're big enough to influence the industry to switch to using highly identifiable patterns for API keys. However, it's at the expense of scanning for unstructured secrets (like passwords) where GitHub isn't as deep yet.

TruffleHog has focussed on scanning for credentials _after_ they've leaked. They scan for a broader range of things (including unstructured secrets like passwords). That naturally has a higher false positive rate, which they combat by automatically verifying some of their findings (by making requests to the corresponding services). GitHub does that too (for patterns it can't push protect) but it hasn't gone as deep on it yet. The delta is relatively small, though - as you can imagine, it's a long tail of patterns / credential types.

Right now there's space for both solutions - you want prevention when you can get it (without creating a bad developer experience with false positives), but you also want breadth. In the long run, though, GitHub is probably better positioned to offer both.