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

• Sasha (Software Developer)
• Rachel (Release Manager)
• Alex (Security Operations Engineer)

User experience goal

Lower signal-to-noise ratio for security rules that one's team does not consider significant.

Proposal

Implementation Plan

1. 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 as identifier.type and identifier.value)
2. Update analyzers/command/run.go to filter out disabled rules
3. Check GITLAB_PLAN for rule disablement
4. 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?

GitLab Ultimate

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.