SAST rules

GitLab SAST uses a set of analyzers to scan code for potential vulnerabilities. Each analyzer processes the code then uses rules to find possible weaknesses in source code. The rules determine what types of weaknesses the analyzer reports.

Source of rules

Semgrep-based analyzer

GitLab creates, maintains, and supports the rules that are used in the Semgrep-based GitLab SAST analyzer. This analyzer scans many languages in a single CI/CD pipeline job. It combines:

Other analyzers

GitLab SAST uses other analyzers to scan the remaining supported languages. The rules for these scans are defined in the upstream projects for each scanner.

How rule updates are released

GitLab updates rules regularly based on customer feedback and internal research. Rules are released as part of the container image for each analyzer. You automatically receive updated analyzers and rules unless you manually pin analyzers to a specific version.

Analyzers and their rules are updated at least monthly if relevant updates are available.

The GitLab ruleset for the Semgrep-based analyzer is managed in the GitLab-managed open-source sast-rules project. When rules are updated, they’re released as part of the Semgrep-based analyzer’s container image.

Configure rules in your projects

You should use the default SAST rules unless you have a specific reason to make a change. The default ruleset is designed to be relevant to most projects.

However, you can customize which rules are used or control how rule changes are rolled out if needed.

Apply local rule preferences

You may want to customize the rules used in SAST scans because:

  • Your organization has assigned priorities to specific vulnerability classes, such as choosing to address Cross-Site Scripting (XSS) or SQL Injection before other classes of vulnerabilities.
  • You believe that a specific rule is a false positive result or isn’t relevant in the context of your codebase.

To change which rules are used to scan your projects, adjust their severity, or apply other preferences, see Customize rulesets. If your customization would benefit other users, consider reporting a problem to GitLab.

Coordinate rule rollouts

To control the rollout of rule changes, you can pin SAST analyzers to a specific version.

If you want to make these changes at the same time across multiple projects, consider setting the variables in:

Report a problem with a GitLab SAST rule

GitLab welcomes contributions to the rulesets used in SAST. Contributions might address:

  • False positive results, where the potential vulnerability is incorrect.
  • False negative results, where SAST did not report a potential vulnerability that truly exists.
  • The name, severity rating, description, guidance, or other explanatory content for a rule.

If you believe a detection rule could be improved for all users, consider:

Important rule changes

GitLab updates SAST rules regularly. This section highlights the most important changes. More details are available in release announcements and in the CHANGELOG links provided.

Rule changes in the Semgrep-based analyzer

Key changes to the GitLab-managed ruleset for Semgrep-based scanning include:

  • Beginning in GitLab 16.3, the GitLab Static Analysis and Vulnerability Research teams are working to remove rules that tend to produce too many false positive results or not enough actionable true positive results. Existing findings from these removed rules are automatically resolved; they no longer appear in the Security Dashboard or in the default view of the Vulnerability Report. This work is tracked in epic 10907.
  • In GitLab 16.0 through 16.2, the GitLab Vulnerability Research team updated the guidance that’s included in each result.
  • In GitLab 15.10, the detect-object-injection rule was removed by default and its findings were automatically resolved.

For more details, see the CHANGELOG for sast-rules.

Rule changes in other analyzers

See the CHANGELOG file for each analyzer for details of the changes, including new or updated rules, included in each version.