SAST Custom Rules - Disabling Pre-existing Rules
Problem to solve
To complete Custom Rulesets for SAST Analyzers we should provide the ability to disable specific rules for our individual Category:SAST analyzers.
Intended users
User experience goal
Lower signal-to-noise ratio for security rules that one's team does not consider significant.
Proposal
Implementation Plan
- Update SAST rules configuration file specification to allow individual rules to be set as
disable = true
. These rules must match the any identifier as defined by a given analyzer using predefined filter attributes (such asidentifier.type
andidentifier.value
) - Update
analyzers/command/run.go
to filter out disabled rules - Check
GITLAB_PLAN
for rule disablement - Document functionality within Static Application Security Testing docs !47847 (merged)
Update SAST analyzers common version and add report.Analyzer
/report.Config.Path
-
gosec gitlab-org/security-products/analyzers/gosec!79 (merged) -
nodejs-scan gitlab-org/security-products/analyzers/nodejs-scan!83 (merged) -
secrets gitlab-org/security-products/analyzers/secrets!86 (merged) -
pmd-apex gitlab-org/security-products/analyzers/pmd-apex!47 (merged) -
spotbugs gitlab-org/security-products/analyzers/spotbugs!79 (merged) -
sobelow gitlab-org/security-products/analyzers/sobelow!44 (merged) -
security-code-scan gitlab-org/security-products/analyzers/security-code-scan!58 (merged) -
brakeman gitlab-org/security-products/analyzers/brakeman!50 (merged) -
bandit gitlab-org/security-products/analyzers/bandit!59 (merged) -
flawfinder gitlab-org/security-products/analyzers/flawfinder!44 (merged) -
phpcs-security-audit gitlab-org/security-products/analyzers/phpcs-security-audit!46 (merged) -
eslint gitlab-org/security-products/analyzers/eslint!62 (merged) -
mobSF gitlab-org/security-products/analyzers/mobsf!9 (merged) -
kubesec gitlab-org/security-products/analyzers/kubesec!39 (merged)
Future iterations may handle this more efficiently by disabling rules for the analyzer execution itself (don't even try to find rules that are disabled) but we can consider this optimization later.
Example
[spotbugs]
[[spotbugs.ruleset]]
# Properties to filter on
[spotbugs.ruleset.identifier]
type = "find_sec_bugs_type" # not needed but for readability
value = "PREDICTABLE_RANDOM"
disable = true
Further details
Permissions and Security
No change to permissions
Documentation
Document functionality within Static Application Security Testing docs
Done with !47847 (diffs)
Availability & Testing
- Add test ensuring disabled rule does not yield findings in generated reports
What does success look like, and how can we measure that?
Rules can be disabled if considered insignificant to users
What is the type of buyer?
Is this a cross-stage feature?
Links / references
Release Notes
Building off the success of our previously released Custom rulesets, we are now enabling customers to disable existing default rule sets. This allows organizations to disable rules they wish to ignore or find generate too many false positive results.