Make a crate / programmatic interface

[SaadBazaz]

Hello!
Was checking out the project and think it's cool. If this does what I think it does, i.e. it can scan a certain line for secrets using regexes / checks, are you planning to make a crate for it?

Reason: We are building out secret scanning in Biome (biomejs/biome#4118) and thought it more useful to use existing community solutions instead of building out our own. So with a crate for sensleak-rs, we can at least gauge if it's useful for our use-case.

[yaokunzhang]

Hi! Thanks for checking out the project and for your interest. I’ve actually been involved in the development of sensleak-rs, and I’m planning to take on this issue soon. We haven’t prepared for secret scanning like this in the past, but I’ll be starting work on it in the near future. Creating a crate is definitely something we’re considering, and it’s great to hear that Biome is building out secret scanning. I believe sensleak-rs could fit well with your use case. I’ll keep you updated on the crate’s progress, and please feel free to reach out if you have any specific requirements or ideas that could align with your project.

[SaadBazaz]

@yaokunzhang of course! Excited to see you taking this up! Please keep me in the loop on the progress, and do let me know if you need any help. Feel free to join the Biome Discord to alert the rest of the maintainers too.

https://discord.gg/UFeXWDpnhd

[SaadBazaz]

I'd highly recommend that you check out our existing implementation for secret scanning in Biome. Maybe you can recommend changes / improvements by utilizing sensleaks (or without it!)

Edit: Just an idea while passing by this again, maybe you can separate sensleak-rs and sensleak-core-rs (i.e. just the regex / secret scanning util functions) so that the dependencies are largely reduced if we just directly use the core library in Biome.

[yaokunzhang]

@SaadBazaz
Hello! Last month I was occupied with some other tasks, but now I'm ready to resume work on sensleak. I checked out some of the code you mentioned in the issue, and if I’m not mistaken, the main part that detects sensitive information leaks seems to be in no_secret.rs.

I have a few suggestions regarding your implementation:

1. Have you considered moving the detection rules into a configuration file that can be loaded at runtime? This might make it more flexible and customizable.
2. Including an allowlist table for specific rules could help reduce false positives or allow ignoring commits with known/rotated secrets.

Additionally, regarding the development of sensleak as a crate, if you have any specific requirements—such as interfaces you’d like abstracted for easier integration—please feel free to share. I'd be glad to support your team’s needs in any way I can.