HN user

zricethezav

67 karma

Author of Gitleaks/Maintainer of Betterleaks

Looking for secrets

Posts4
Comments20
View on HN

I've been working on Betterleaks for the past three months. It's the successor to Gitleaks since I'm not focused on that project much anymore. I just released v1.2.0 which added GitHub as a source to scan for secrets against and a new filtering system powered by CEL for more expressiveness.

https://betterleaks.com

8 years ago I wrote the first lines of Gitleaks and have been hooked on finding leaked secrets since. Gitleaks grew from a small project to a name recognized by developers and security folks. It sucks but I gotta take a step back from the project. I'll cut security releases but don't expect any new features from me. But I'm not stepping back from secrets scanning! I'm working full time on maintaining Betterleaks, a drop-in replacement for Gitleaks with some fun new features and improvements like rule-defined validation, faster scans, new filters like token efficiency, and more.

Happy to chat about it and sorry if this causes any migration headache

`alias gitleaks='betterleaks'` should do the trick

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.

FWIW, here is a blog post explaining the rationale behind starting an LLC https://blog.gitleaks.io/gitleaks-llc-announcement-d7d06a52e...

`pass` by itself might introduce false positives. `passwd` and `password` are common and more likely to be in the ROI of a secret. That said, I'm not opposed to `pass` by itself. I'll have to think about this one...

but I assume they were chosen based on the statistics?

Nope, not statistics. Identifiers and keywords are chosen based on what I see out in the wild being a software engineer.

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].

[1] https://regex101.com/r/CLg9TK/1

[2] https://github.com/zricethezav/gitleaks/blob/master/config/g...

[3] https://github.com/zricethezav/gitleaks/blob/master/cmd/gene...