SARIF reports

Use third-party SARIF reports to add findings from any SARIF 2.1.0 scanner into GitLab vulnerability management. A CI/CD job runs a SARIF-producing scanner and adds a SARIF artifact. GitLab parses, validates, and adds the artifacts as security findings.

After you add the report, findings appear alongside findings from native GitLab scanners in the following pages:

• The pipeline Security tab
• The project vulnerability report
• The security dashboard
• The merge request security widget
• Security policies

Third-party SARIF reports complement the built-in scanners that GitLab offers. Use them to integrate a third-party scanner that GitLab does not provide natively, or to consolidate findings from a tool you already run.

Add SARIF reports

To add SARIF findings into GitLab:

Prerequisites:

• The Maintainer or Owner role for the project.
• A CI/CD job that produces a SARIF 2.1.0 file.

1. In your .gitlab-ci.yml file, define a job that runs the scanner and saves its SARIF output as an artifacts:reports:sarif artifact. Example:

   sarif_scan:
     image: <scanner-image>
     script:
       - <scanner-command> --output sarif.json
     artifacts:
       reports:
         sarif: sarif.json

2. Commit and push the change. GitLab parses the SARIF file when the job completes.

3. View the added findings in the pipeline Security tab.

For the CI/CD artifact reference, see artifacts:reports:sarif.

Assigned report types

GitLab assigns a vulnerability report type for each SARIF finding based on the finding’s location and identifiers. The type determines where the finding appears in the vulnerability report and how it interacts with security policies.

GitLab evaluates the following rules in order and assigns the first type that matches the finding.

Footnotes:

1. The following CWEs are secret-related:

   • CWE-798 (Hard-coded credentials).
   • CWE-259 (Hard-coded password).
   • CWE-321 (Hard-coded cryptographic key).
   • CWE-522 (Insufficiently protected credentials).
   • CWE-312 (Cleartext storage of sensitive information).
   • CWE-319 (Cleartext transmission of sensitive information).
   • CWE-256 (Plaintext storage of a password).
   • CWE-257 (Storing passwords in a recoverable format).
   • CWE-540 (Inclusion of sensitive information in source code).

GitLab reads identifiers from three sources in a result and its rule, in this order:

1. result.ruleId when the entry matches the format CVE-YYYY-N or CWE-N.
2. rule.properties.tags[] when the entry matches the format cwe:N, cwe-N, cve:YYYY-N, or cve-YYYY-N.
3. rule.relationships[] when the relationship’s target.toolComponent.name is CWE.

SARIF field mapping

GitLab assigns SARIF fields to fields that are compatible with GitLab according to the following rules.

Severity resolution

GitLab resolves the severity of a SARIF finding by checking the following fields in priority order. The first field that has a value is used.

1. result.rank. A float from 0.0 to 100.0.
2. rule.properties.security-severity. A float from 0.0 to 10.0. The value is multiplied by 10 before bucketing.
3. result.properties.security-severity. A float from 0.0 to 10.0. The value is multiplied by 10 before bucketing.
4. result.level.
5. rule.defaultConfiguration.level.
6. medium as the default if no other matches.

Numeric scores from result.rank or security-severity are assigned as severities using these ranges:

SARIF level values are mapped as follows:

Ingestion behavior

When the SARIF file is well-formed but some of the results cannot be added, GitLab uses the percentage of results that it could not process to decide what to do with the scan as a whole.

GitLab cannot process a result in any of the following cases:

• The ruleId is missing.
• The physicalLocation is missing.
• Any of the required components used to generate the finding identifier are nil.

The drop rate is calculated across the entire SARIF artifact, not for each run in the file. When the share of unprocessable results across all runs exceeds the threshold, the ingestion feedback is applied to every report emitted from the artifact.

Schema validation errors and unsupported SARIF versions cause the whole report to be rejected, regardless of drop rate.

Multi-tool reports

A SARIF file can contain multiple tool runs, each with its own runs[] entry. For each run, GitLab groups the findings by inferred report type and creates a separate scan record for each group. A run that contains findings of more than one inferred type produces more than one scan record. Each scan uses the run’s tool.driver.name as its scanner.

Use multi-run reports to combine the output of several scanners into a single artifact. For example, a job can run two scanners and emit a single SARIF file that contains two runs.

Each report must contain fewer than 20 runs.

Limits

For GitLab Self-Managed instances, an administrator can change configurable limits through the instance limits.

Known issues

• SARIF findings assigned as SAST, dependency scanning, or secret detection are not deduplicated against findings from the equivalent native GitLab scanner. For details, see issue 592410.
• Although findings can be excluded through SARIF suppressions, GitLab does not create vulnerability dismissals based on suppressions. To dismiss a finding, use the vulnerability report.

Related topics

• artifacts:reports:sarif
• Pipeline security report
• Project vulnerability report
• Security policies
• SARIF 2.1.0 specification