SAST rules

DETAILS: Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab SAST uses a set of analyzers to scan code for potential vulnerabilities. It automatically chooses which analyzers to run based on which programming languages are found in the repository.

Each analyzer processes the code, then uses rules to find possible weaknesses in source code. The analyzer's rules determine what types of weaknesses it reports.

Scope of rules

GitLab SAST focuses on security weaknesses and vulnerabilities. It does not aim to find general bugs or assess overall code quality or maintainability.

GitLab manages the detection ruleset with a focus on identifying actionable security weaknesses and vulnerabilities. The ruleset is designed to provide broad coverage against the most impactful vulnerabilities while minimizing false positives (reported vulnerabilities where no vulnerability exists).

GitLab SAST is designed to be used in its default configuration, but you can configure detection rules if needed.

Source of rules

Advanced SAST

DETAILS: Tier: Ultimate

GitLab creates, maintains, and supports the rules for Advanced SAST. Its rules are custom-built to leverage the Advanced SAST scanning engine's cross-file, cross-function analysis capabilities. The Advanced SAST ruleset is not open source, and is not the same ruleset as any other analyzer.

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:

the Semgrep open-source engine.
a GitLab-managed detection ruleset, which is managed in the GitLab-managed open source sast-rules project.
GitLab proprietary technology for vulnerability tracking.

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.

Rule update policies

Updates to SAST rules are not breaking changes. This means that rules may be added, removed, or updated without prior notice.

However, to make rule changes more convenient and understandable, GitLab:

Documents rule changes that are planned or completed.
Automatically resolves findings from rules after they are removed for Semgrep-based analyzers.
Enables you to change the status on vulnerabilities where activity = "no longer detected" in bulk.
Evaluates proposed rule changes for the impact they will have on existing vulnerability records.

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:

Group-level CI/CD variables.
Custom CI/CD variables in a Scan Execution Policy.

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:

Submitting a merge request to the sast-rules repository. See the contribution instructions for details.
Filing an issue in the gitlab-org/gitlab issue tracker.
- Post a comment that says @gitlab-bot label ~"group::static analysis" ~"Category:SAST" so your issue lands in the correct triage workflow.

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.