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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
|
---
stage: Govern
group: Threat Insights
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
---
# Vulnerability Page **(ULTIMATE ALL)**
Each vulnerability in a project has a vulnerability page containing details of the vulnerability,
including:
- Description
- When it was detected
- Current status
- Available actions
- Linked issues
- Actions log
If the scanner determined the vulnerability to be a false positive, an alert message is included at
the top of the vulnerability's page.
When a vulnerability is no longer detected in a project's default branch, you should
change its status to **Resolved**. This ensures that if it is accidentally reintroduced in a future
merge, it is reported again as a new record. To change the status of multiple vulnerabilities, use
the Vulnerability Report's [Activity filter](../vulnerability_report/index.md#activity-filter).
## Explaining a vulnerability **(ULTIMATE SAAS BETA)**
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10368) in GitLab 16.0 as an [Experiment](../../../policy/experiment-beta-support.md#experiment) on GitLab.com.
> - Promoted to [Beta](../../../policy/experiment-beta-support.md#beta) status in GitLab 16.2.
GitLab can help you with a vulnerability by using a large language model to:
- Summarize the vulnerability.
- Help developers and security analysts to understand the vulnerability, how it could be exploited, and how to fix it.
- Provide a suggested mitigation.
### Explain a vulnerability
Explain a vulnerability with GitLab Duo Vulnerability summary. Use the explanation to better
understand a vulnerability and its possible mitigation.
Prerequisites:
- You must have the GitLab Ultimate subscription tier.
- You must be a member of the project.
- The vulnerability must be a SAST finding.
Learn more about [how to enable all GitLab Duo features](../../ai_features.md#enable-aiml-features).
To explain the vulnerability:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Security and Compliance > Vulnerability report**.
1. In the **Tool** dropdown list, select **SAST**.
1. Select the SAST vulnerability you want explained.
1. At the bottom of the vulnerability's page, select **Try it out**.
The response is shown on the right side of the page.
![Explain this vulnerability](img/explain_this_vulnerability_beta_v16_3.png)
On GitLab.com this feature is available. By default, it is powered by Google's `text-bison-001`
model. In the event of degraded performance with that model, the feature instead uses Anthropic's
`claude` model.
We cannot guarantee that the large language model produces results that are correct. Use the
explanation with caution.
### Data shared with third-party AI APIs
The following data is shared with third-party AI APIs:
- Vulnerability title (which might contain the filename, depending on which scanner is used).
- Vulnerability identifiers.
- Code block, but only if the "Send code with prompt" checkbox is selected (single and multi-line as instructed by the vulnerability
record).
- Filename.
## Vulnerability status values
A vulnerability's status can be:
- **Detected**: The default state for a newly discovered vulnerability. Appears as "Needs triage" in the UI.
- **Confirmed**: A user has seen this vulnerability and confirmed it to be accurate.
- **Dismissed**: A user has seen this vulnerability and dismissed it because it is not accurate or
otherwise not to be resolved. Dismissed vulnerabilities are ignored if detected in subsequent
scans.
- **Resolved**: The vulnerability has been fixed or is no longer present. If a resolved
vulnerability is reintroduced and detected again, its record is reinstated and its status set to
detected.
## Vulnerability dismissal reasons
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4942) in GitLab 15.11 with a feature flag named `dismissal_reason`.
> - Enabled on GitLab.com in GitLab 15.11. For self-managed customers, [contact Support](https://about.gitlab.com/support/) if you would like to use this feature in GitLab 15.11.
> - Enabled by default in GitLab 16.0.
When dismissing a vulnerability, one of the following reasons must be chosen to clarify why it is being dismissed:
- **Acceptable risk**: The vulnerability is known, and has not been remediated or mitigated, but is considered to be an acceptable business risk.
- **False positive**: An error in reporting in which a test result incorrectly indicates the presence of a vulnerability in a system when the vulnerability is not present.
- **Mitigating control**: A management, operational, or technical control (that is, safeguard or countermeasure) employed by an organization that provides equivalent or comparable protection for an information system.
- **Used in tests**: The finding is not a vulnerability because it is part of a test or is test data.
- **Not applicable**: The vulnerability is known, and has not been remediated or mitigated, but is considered to be in a part of the application that will not be updated.
## Change status of a vulnerability
To change a vulnerability's status from its Vulnerability Page:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Vulnerability report**.
1. Select the vulnerability's description.
1. From the **Status** dropdown list select a status, then select **Change status**.
In GitLab 15.11 and later, you must select a [dismissal reason](#vulnerability-dismissal-reasons) when you change a vulnerability's status to **Dismissed**.
1. Optionally, at the bottom of the page, add a comment to the log entry.
Details of the status change, including who made the change and when, are recorded in the
vulnerability's action log.
## Creating an issue for a vulnerability
From a vulnerability's page you can create an issue to track all action taken to resolve or
mitigate it.
You can create either:
- [A GitLab issue](#create-a-gitlab-issue-for-a-vulnerability) (default).
- [A Jira issue](#create-a-jira-issue-for-a-vulnerability).
### Create a GitLab issue for a vulnerability
To create a GitLab issue for a vulnerability:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Vulnerability report**.
1. Select the vulnerability's description.
1. Select **Create issue**.
An issue is created in the project, pre-populated with information from the vulnerability report.
The issue is then opened so you can take further action.
### Create a Jira issue for a vulnerability
Prerequisites:
- [Enable Jira integration](../../../integration/jira/index.md). The **Enable Jira issue creation
from vulnerabilities** option must be selected as part of the configuration.
- Each user must have a personal Jira user account with permission to create issues in the target
project.
To create a Jira issue for a vulnerability:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Vulnerability report**.
1. Select the vulnerability's description.
1. Select **Create Jira issue**.
1. If you're not already logged in to Jira, sign in.
The Jira issue is created and opened in a new browser tab. The **Summary** and **Description**
fields are pre-populated from the vulnerability's details.
Unlike GitLab issues, the status of whether a Jira issue is open or closed does not display in the
GitLab user interface.
## Linking a vulnerability to GitLab and Jira issues
You can link a vulnerability to one or more existing [GitLab](#create-a-gitlab-issue-for-a-vulnerability)
or [Jira](#create-a-jira-issue-for-a-vulnerability) issues. Only one linking feature is available at the same time.
Adding a link helps track the issue that resolves or mitigates a vulnerability.
### Link a vulnerability to existing GitLab issues
Prerequisite:
- [Jira issue integration](../../../integration/jira/configure.md) must not be enabled.
To link a vulnerability to existing GitLab issues:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Vulnerability report**.
1. Select the vulnerability's description.
1. In the **Linked issues** section, select the plus icon (**{plus}**).
1. For each issue to be linked, either:
- Paste a link to the issue.
- Enter the issue's ID (prefixed with a hash `#`).
1. Select **Add**.
The selected GitLab issues are added to the **Linked items** section, and the linked issues counter is
updated.
GitLab issues linked to a vulnerability are shown in the Vulnerability Report and the vulnerability's page.
Be aware of the following conditions between a vulnerability and a linked GitLab issue:
- The vulnerability page shows related issues, but the issue page doesn't show the vulnerability
it's related to.
- An issue can only be related to one vulnerability at a time.
- Issues can be linked across groups and projects.
### Link a vulnerability to existing Jira issues
Prerequisite:
- [Jira issue integration](../../../integration/jira/configure.md) must be enabled, with option **Enable Jira issue creation from vulnerabilities** also enabled.
To link a vulnerability to existing Jira issues, add the following line to the Jira issue's description:
```plaintext
/-/security/vulnerabilities/<id>
```
`<id>` is any [vulnerability ID](../../../api/vulnerabilities.md#single-vulnerability).
You can add several lines with different IDs to one description.
Jira issues with appropriate description are added to the **Related Jira issues** section, and the linked issues counter is
updated.
Jira issues linked to a vulnerability are shown only on the vulnerability page.
Be aware of the following conditions between a vulnerability and a linked Jira issue:
- The vulnerability page and the issue page show the vulnerability they are related to.
- An issue can be related to one or more vulnerabilities at the same time.
## Resolve a vulnerability
For some vulnerabilities a solution is already known. In those instances, a vulnerability's page
includes a **Resolve with merge request** option.
The following scanners are supported by this feature:
- [Dependency Scanning](../dependency_scanning/index.md).
Automatic patch creation is only available for Node.js projects managed with
`yarn`. Also, Automatic patch creation is only supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is disabled.
- [Container Scanning](../container_scanning/index.md).
To resolve a vulnerability, you can either:
- [Resolve a vulnerability with a merge request](#resolve-a-vulnerability-with-a-merge-request).
- [Resolve a vulnerability manually](#resolve-a-vulnerability-manually).
![Create merge request from vulnerability](img/create_mr_from_vulnerability_v13_4.png)
### Resolve a vulnerability with a merge request
To resolve the vulnerability with a merge request:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Vulnerability report**.
1. Select the vulnerability's description.
1. From the **Resolve with merge request** dropdown list, select **Resolve with merge request**.
A merge request is created which applies the patch required to resolve the vulnerability.
Process the merge request according to your standard workflow.
### Resolve a vulnerability manually
To manually apply the patch that GitLab generated for a vulnerability:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Vulnerability report**.
1. Select the vulnerability's description.
1. From the **Resolve with merge request** dropdown list, select **Download patch to resolve**.
1. Ensure your local project has the same commit checked out that was used to generate the patch.
1. Run `git apply remediation.patch`.
1. Verify and commit the changes to your branch.
1. Create a merge request to apply the changes to your main branch.
1. Process the merge request according to your standard workflow.
## Enable security training for vulnerabilities
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6176) in GitLab 14.9.
NOTE:
Security training is not accessible in an environment that is offline, meaning computers that are isolated from the public internet as a security measure. Some third-party training vendors may require you to sign up for a _free_ account. Sign up for an account by going to
any of [Secure Code Warrior](https://www.securecodewarrior.com/), [Kontra](https://application.security/), or [SecureFlag](https://www.secureflag.com/).
GitLab does not send any user information to these third-party vendors; we do send the CWE or OWASP identifier and the language name of the file extension.
Security training helps your developers learn how to fix vulnerabilities. Developers can view security training from selected educational providers, relevant to the detected vulnerability.
To enable security training for vulnerabilities in your project:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Security configuration**.
1. On the tab bar, select **Vulnerability Management**.
1. To enable a security training provider, turn on the toggle.
Each integration submits the Vulnerability identifier, for example CWE or OWASP, and the language to the security training vendor. The resulting link to the vendor training is what appears in a GitLab Vulnerability.
## View security training for a vulnerability
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6176) in GitLab 14.9.
The vulnerability page may include a training link relevant to the detected vulnerability if security training is enabled.
The availability of training depends on whether the enabled training vendor has content matching the particular vulnerability.
Training content is requested based on the [vulnerability identifiers](../../../development/integrations/secure.md#identifiers).
The identifier given to a vulnerability varies from one vulnerability to the next and the available training
content varies between vendors. Some vulnerabilities do not display training content.
Vulnerabilities with a CWE are most likely to return a training result.
To view the security training for a vulnerability:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Secure > Vulnerability report**.
1. Select the vulnerability for which you want to view security training.
1. Select **View training**.
|