In GitLab 14.10 and later, report validation against the schemas is enabled. To enable report validation for versions earlier than 14.10,
set [`VALIDATE_SCHEMA`](../../user/application_security/#enable-security-report-validation) to
`"true"`.
Reports that don't pass validation are not ingested by GitLab, and an error message
displays on the corresponding pipeline.
You should ensure that reports generated by the scanner pass validation against the schema version
declared in your reports. GitLab uses the
[`json_schemer`](https://www.rubydoc.info/gems/json_schemer) gem to perform validation.
Ongoing improvements to report validation is tracked [in this epic](https://gitlab.com/groups/gitlab-org/-/epics/6968).
### Report Fields
#### Version
This field specifies the version of the [Security Report Schemas](https://gitlab.com/gitlab-org/security-products/security-report-schemas) you are using. Please refer to the [releases](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/releases) of the schemas for the specific versions to use.
This field specifies which [Security Report Schemas](https://gitlab.com/gitlab-org/security-products/security-report-schemas) version you are using. For information about the versions to use, see [releases](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/releases).
In GitLab 14.10 and later, GitLab validates your report against the version of the schema specified by this value.
tab do not enforce this limit and all identifiers present in the report artifact are displayed.
### Details
#### Details
The `details` field is an object that supports many different content elements that are displayed when viewing vulnerability information. An example of the various data elements can be seen in the [security-reports repository](https://gitlab.com/gitlab-examples/security/security-reports/-/tree/master/samples/details-example).
### Location
#### Location
The `location` indicates where the vulnerability has been detected.
The format of the location depends on the type of scanning.
...
...
@@ -458,7 +480,7 @@ which is used to track vulnerabilities
as new commits are pushed to the repository.
The attributes used to generate the location fingerprint also depend on the type of scanning.
#### Dependency Scanning
##### Dependency Scanning
The `location` of a Dependency Scanning vulnerability is composed of a `dependency` and a `file`.
The `dependency` object describes the affected `package` and the dependency `version`.
...
...
@@ -488,7 +510,7 @@ combines the `file` and the package `name`,
so these attributes are mandatory.
All other attributes are optional.
#### Container Scanning
##### Container Scanning
Similar to Dependency Scanning,
the `location` of a Container Scanning vulnerability has a `dependency` and a `file`.
...
...
@@ -519,7 +541,7 @@ so these attributes are mandatory.
The `image` is also mandatory.
All other attributes are optional.
#### Cluster Image Scanning
##### Cluster Image Scanning
The `location` of a `cluster_image_scanning` vulnerability has a `dependency` field. It also has
an `operating_system` field. For example, here is the `location` object for a vulnerability
...
...
@@ -553,7 +575,7 @@ as well as the package `name`, so these fields are required. The `image` field i
The `cluster_id` and `agent_id` are mutually exclusive, and one of them must be present.
All other fields are optional.
#### SAST
##### SAST
The `location` of a SAST vulnerability must have a `file` and a `start_line` field,
giving the path of the affected file, and the affected line number, respectively.
...
...
@@ -578,7 +600,7 @@ combines `file`, `start_line`, and `end_line`,
so these attributes are mandatory.
All other attributes are optional.
### Tracking and merging vulnerabilities
#### Tracking and merging vulnerabilities
Users may give feedback on a vulnerability:
...
...
@@ -606,7 +628,7 @@ and at least one [identifier](#identifiers). Two identifiers are the same if the
CWE and WASC identifiers are not considered because they describe categories of vulnerability flaws,
but not specific security flaws.
#### Severity and confidence
##### Severity and confidence
The `severity` field describes how much the vulnerability impacts the software,
whereas the `confidence` field describes how reliable the assessment of the vulnerability is.