Update Secrets Scanner to support custom rules
Problem to solve
Users are constrained to use the secrets rules we provide which is limited and does not cover many use cases like #210496. Instead we should give users the ability to define what secrets they want to search. This can be done by creating our own rule config and translating it into the custom rules we have now or we could use the gitleaks config toml -- some examples of that here.
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
A great example is this issue #210496. The user wanted to make sure the secrets analyzer picks up passwords in JDBC connection strings. We could hardcode the rule into the secrets analyzer or we could let the user define their own rules which would include the ability to whitelist, resulting in less false positives.
Add similar support as SAST Custom Rules - Passthrough Scanner Configuration to the secrets analyzer analyzer. This would allow a user to define a gitleaks.toml embedded in
.gitlab/secret-detection-ruleset.toml or in a file with the location defined in the
.gitlab/secret-detection-ruleset.toml. The biggest difference with this and the old proposal is that this would be an override rather than additive to the current secrets analyzer rules.
Support through MRs to files in project repositories is the only addition method supported. Adding this capability to a Configuration UI is out of scope for this issue.
- Allow customers to provide a toml file declaring rules in the same format as gitleaks.toml.
- Add variable (or variables) allowing customers to declare where additional rules are defined.
- Initial support is limited to additional rules provided as part of the project being built.
- Customer-provided rules would be additive to the rules provided by the secrets scanner.
- If customers provide rules whose description matches one provided by secrets, the customer provided rule replaces it.
Permissions and Security
We should update the SAST documentation and explain how the rule config works.