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
|
---
type: reference, howto
stage: Secure
group: Threat Insights
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Vulnerability Pages **(ULTIMATE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13561) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.0.
Each security vulnerability in a project's [Vulnerability Report](../vulnerability_report/index.md) has an individual page which includes:
- Details of the vulnerability.
- The status of the vulnerability in the project.
- Available actions for the vulnerability.
- Any issues related to the vulnerability.
On the vulnerability's page, you can:
- [Change the vulnerability's status](#change-vulnerability-status).
- [Create an issue](#create-an-issue-for-a-vulnerability).
- [Link issues to the vulnerability](#link-gitlab-issues-to-the-vulnerability).
- [Remediate a vulnerability automatically](#remediate-a-vulnerability-automatically), if an
automatic solution is available.
- [Remediate a vulnerability manually](#remediate-a-vulnerability-manually), if a solution is
available.
## Change vulnerability status
You can change the status of a vulnerability using the **Status** dropdown to one of
the following values:
| Status | Description |
|-----------|----------------------------------------------------------------------------------------------------------------|
| Detected | The default state for a newly discovered vulnerability |
| 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 |
| Resolved | The vulnerability has been fixed and is no longer valid |
A timeline shows you when the vulnerability status has changed
and allows you to comment on a change.
## Create 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.
From a vulnerability 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).
Creating a Jira issue requires that
[Jira integration](../../../integration/jira/index.md) is enabled on the project. Note
that when Jira integration is enabled, the GitLab issue feature is not available.
### Create a GitLab issue for a vulnerability
To create a GitLab issue for a vulnerability:
1. In GitLab, go to the vulnerability's page.
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
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4677) in GitLab 13.9.
> - It's [deployed behind a feature flag](../../../user/feature_flags.md), enabled by default.
> - It's enabled on GitLab.com.
> - It's recommended for production use.
> - For GitLab self-managed instances, GitLab administrators can opt to
> [disable it](#enable-or-disable-jira-integration-for-vulnerabilities).
WARNING:
This feature might not be available to you. Check the **version history** note above for details.
Prerequisites:
- [Enable Jira integration](../../project/integrations/jira.md).
The **Enable Jira issues 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. Go to the vulnerability's page.
1. Select **Create Jira issue**.
1. If you're not already logged in to Jira, log 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.
### Enable or disable Jira integration for vulnerabilities **(ULTIMATE SELF)**
The option to create a Jira issue for a vulnerability is under development but ready for production
use. It is deployed behind a feature flag that is **enabled by default**.
[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
can opt to disable it.
To enable it:
```ruby
Feature.enable(:jira_for_vulnerabilities)
```
To disable it:
```ruby
Feature.disable(:jira_for_vulnerabilities)
```
## Link GitLab issues to the vulnerability
NOTE:
If Jira issue support is enabled, GitLab issues are disabled so this feature is not available.
You can link one or more existing GitLab issues to the vulnerability. This allows you to
indicate that this vulnerability affects multiple issues. It also allows you to indicate
that the resolution of one issue would resolve multiple vulnerabilities.
Linked issues are shown in the Vulnerability Report and the vulnerability's page.
## Link to an existing issue
If you already have an open issue, you can link to it from the vulnerability.
- 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.
To link to an existing issue:
1. Open the vulnerability.
1. [Add a linked issue](../../project/issues/related_issues.md).
## Remediate a vulnerability automatically
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5656) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.7.
Some vulnerabilities can be fixed by applying the solution that GitLab automatically generates.
The following scanners are supported:
- [Dependency Scanning](../dependency_scanning/index.md).
Automatic Patch creation is only available for Node.js projects managed with
`yarn`.
- [Container Scanning](../container_scanning/index.md).
### Remediate a vulnerability manually
To manually apply the patch that GitLab generated for a vulnerability:
1. Select the **Resolve with merge request** dropdown, then 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.
### Create a merge request with the suggested patch
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9224) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.9.
In some cases, you can create a merge request that automatically remediates the
vulnerability. Any vulnerability that has a
[solution](#remediate-a-vulnerability-automatically) can have a merge
request created to automatically solve the issue.
If this action is available:
1. Select the **Resolve with merge request** dropdown, then select **Resolve with merge request**.
A merge request is created. It applies the solution to the source branch.
## Vulnerability scanner maintenance
The following vulnerability scanners and their databases are regularly updated:
| Secure scanning tool | Vulnerabilities database updates |
|:----------------------------------------------------------------|----------------------------------|
| [Container Scanning](../container_scanning/index.md) | Uses either `trivy` or `clair`. For the `trivy` scanner, a job runs on a daily basis to build a new image with the latest vulnerability database updates from the [upstream `trivy-db`](https://github.com/aquasecurity/trivy-db). For the `clair` scanner, the latest `clair-db` version is used; `clair-db` database [is updated daily according to the author](https://github.com/arminc/clair-local-scan#clair-server-or-local). |
| [Dependency Scanning](../dependency_scanning/index.md) | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for npm packages), and `gemnasium` (the GitLab tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
| [Dynamic Application Security Testing (DAST)](../dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/master/Dockerfile#L1). The scanning rules are downloaded at scan runtime. |
| [Static Application Security Testing (SAST)](../sast/index.md) | Relies exclusively on [the tools GitLab wraps](../sast/index.md#supported-languages-and-frameworks). The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. |
You do not have to update GitLab to benefit from the latest vulnerabilities definitions.
The security tools are released as Docker images. The vendored job definitions that enable them use
major release tags according to [semantic versioning](https://semver.org/). Each new release of the
tools overrides these tags.
The Docker images are updated to match the previous GitLab releases. Although
you automatically get the latest versions of the scanning tools,
there are some [known issues](https://gitlab.com/gitlab-org/gitlab/-/issues/9725)
with this approach.
|
