1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
---
stage: Secure
group: Static Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# SAST rules **(FREE)**
GitLab SAST uses a set of [analyzers](analyzers.md) 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](index.md#supported-languages-and-frameworks) in a single CI/CD pipeline job.
It combines:
- the Semgrep open-source engine.
- GitLab-managed detection rules.
- GitLab proprietary technology for [vulnerability tracking](index.md#advanced-vulnerability-tracking) and [false positive detection](index.md#false-positive-detection).
### Other analyzers
GitLab SAST uses other analyzers to scan the remaining [supported languages](index.md#supported-languages-and-frameworks).
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](index.md#pinning-to-minor-image-version).
Analyzers and their rules are updated [at least monthly](../index.md#vulnerability-scanner-maintenance) if relevant updates are available.
The GitLab ruleset for the Semgrep-based analyzer is managed in [the GitLab-managed open-source `sast-rules` project](https://gitlab.com/gitlab-org/security-products/sast-rules).
When rules are updated, they're released as part of the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)'s container image.
### Rule update policies
Updates to SAST rules are not [breaking changes](../../../update/terminology.md#breaking-change).
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](#important-rule-changes) that are planned or completed.
- [Automatically resolves](index.md#automatic-vulnerability-resolution) 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](../vulnerability_report/index.md#change-status-of-vulnerabilities).
- 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](#apply-local-rule-preferences) or [control how rule changes are rolled out](#coordinate-rule-rollouts) 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](customize_rulesets.md).
If your customization would benefit other users, consider [reporting a problem to GitLab](#report-a-problem-with-a-gitlab-sast-rule).
### Coordinate rule rollouts
To control the rollout of rule changes, you can [pin SAST analyzers to a specific version](index.md#pinning-to-minor-image-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](../../../ci/variables/index.md#for-a-group).
- Custom CI/CD variables in a [Scan Execution Policy](../policies/scan-execution-policies.md).
## Report a problem with a GitLab SAST rule
<!-- This title is intended to match common search queries users might make. -->
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](https://gitlab.com/gitlab-org/security-products/sast-rules). See the [contribution instructions](https://gitlab.com/gitlab-org/security-products/sast-rules#contributing) for details.
- Filing an issue in [the `gitlab-org/gitlab` issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues/).
- 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](#how-rule-updates-are-released).
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](index.md#automatic-vulnerability-resolution); they no longer appear in the [Security Dashboard](../security_dashboard/index.md#view-vulnerabilities-over-time-for-a-project) or in the default view of the [Vulnerability Report](../vulnerability_report/index.md). This work is tracked in [epic 10907](https://gitlab.com/groups/gitlab-org/-/epics/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](https://gitlab.com/gitlab-org/gitlab/-/issues/373920) and its findings were [automatically resolved](index.md#automatic-vulnerability-resolution).
For more details, see the [CHANGELOG for `sast-rules`](https://gitlab.com/gitlab-org/security-products/sast-rules/-/blob/main/CHANGELOG.md).
### Rule changes in other analyzers
See the CHANGELOG file for each [analyzer](analyzers.md) for details of the changes, including new or updated rules, included in each version.
|
