feat(no-secrets): V2

[SaadBazaz]

Tackles #4113 and #3861

Research

Ever since the creation of this biome plugin originally, I've found various other secret scanning solutions:

1. The OG, gitleaks (Go): https://github.com/gitleaks/gitleaks/
2. Trufflehog (Go): https://github.com/trufflesecurity/trufflehog
3. Sensleak (Rust): https://github.com/crates-pro/sensleak-rs

I've been wondering; Can we consume either one of the above to use in our usecase? Do we really need to add another to the ecosystem?
This I'd like to ask the authors here.

In the meanwhile...

Fixes

• Fix original eslint attribution
• Add better tests for generic use cases

New features planned

Legend:
FP = Feature-Parity with eslint no-secrets (features listed here)

• Add config:
  • Control the entropy (FP)
  • add excludeRegexes
  • add additionalRegexes (FP)
  • checkComments
  • ignoreIdentifiers (FP)
• Add better entropy mechanism
• Add more stopwords and heuristics
  • Contains space
  • Startswith check
• Check for secrets in comments (FP)
• Pass all current tests (FP)

I would love to hear strategies on how to achieve this.

[SaadBazaz]

@minht11 @Conaclos @dyc3 - Would appreciate if you can read the PR description and drop your thoughts.

[dyc3]

I'll defer to the other maintainers for their opinions on adding a dependency for this.

For the proposed options: We generally try to avoid adding options for the sake of adding options. We need an appropriate amount of demand (from users) and justification to determine the correct granularity and scope of those options.

Can we consume either one of the above to use in our usecase? Do we really need to add another to the ecosystem?

Personally, I think a dedicated tool is probably going to have better heuristics than we will, at least in the short term. Plus, we don't take commit history into account like some of those tools do (and we shouldn't, that's not what biome is for).

I think this rule will at least be good for picking out the most egregious cases, with the added benefit that adding the rule to their existing config is easier than adding a new tool to their chain. We could also consider pointing users to a dedicated tool in the diagnostic message and rule documentation. Gitleaks seems to be the most mature.

[minht11]

To add to what @dyc3 said, in my opinion Biome likely isn't a right tool to fully replace full repo secret scanning. Biome does not support all the languages which those tools do and need to be a proper security solution, we have stricter perf constraints and so on.

Having this rule in Biome does help development velocity, no need to wait for CI, and majority of users who wouldn't think about secrets get a warning for common cases, though we definitely should document about full solutions in case users need those.

As for integrations listed:
Sensleak - does not have rust crate, only CLI.
Otherss are GO solutions. Not sure how portable they are, can you call GO lib from rust reasonably? How would the performance be?

[dyc3]

can you call GO lib from rust reasonably?

No. Turbopack had a whole zig helper library to interop between rust and golang while they were porting the project to rust. Definitely not worth the complexity.

[SaadBazaz]

For the proposed options: We generally try to avoid adding options for the sake of adding options. We need an appropriate amount of demand (from users) and justification to determine the correct granularity and scope of those options.

I agree!

There are some features which would make us feature-parity with eslint no-secrets, I've updated the description with a legend to reflect that.

We could also consider pointing users to a dedicated tool in the diagnostic message and rule documentation. Gitleaks seems to be the most mature.
... though we definitely should document about full solutions in case users need those.

Definitely going to do this!

Sensleak - does not have rust crate, only CLI.

I can port some code then 🤠 Or maybe ask their team to make a crate/API for reusability.

No. Turbopack had a whole zig helper library to interop between rust and golang while they were porting the project to rust. Definitely not worth the complexity.

Yikes.

[ematipico]

We usually add options only when required or requested, and when there are valid use cases to cover.

Not sure there's enough value to add yet another dependency for this rule. Sure, it's an important rule, but as the others said, we don't cover all languages. Our documentation could actually propose alternatives to the users.

[Conaclos]

I totally agree with others. The rule should find the most obvious secret leaks and avoid false positives because users might get annoyed and turn off the rule (that defeat its purpose).

We could add a disclaimer in the rule description saying that and point to relevant tools (as the one you cited) for advanced secret leak detections.