Problem
GitLab's CI/CD has first-class support for ingesting security findings via Security Report artifacts (dependency scanning, container scanning, etc.), which populate the vulnerability and dependency dashboards. Today, consuming osv-scanner results in GitLab requires converting the SARIF output to GitLab's format out-of-band (see #599), which is lossy and fragile.
There's also no first-class GitLab CI integration, whereas osv-scanner offers reusable GitHub Actions workflows (docs, google/osv-scanner-action).
Proposal
1. A native gitlab output format so results can be consumed directly by GitLab:
osv-scanner scan --format gitlab ...
- Produce a dependency-scanning report by default, or a container-scanning report when the scan has image metadata (auto-detected).
- Map OSV vulnerabilities to GitLab's schema: identifiers (CVE, CWE, GHSA, USN, RHSA, ELSA, OSVDB, HackerOne, GLAM, MAL, …), severity (derived from the most recent available CVSS vector), CVSS vectors, and reference links.
- Validate output against GitLab's official dependency- and container-scanning report schemas.
2. A GitLab CI/CD Component (published to the CI/CD Catalog), mirroring the convenience of the reusable GitHub Actions workflows. A user could then add osv-scanner scanning with a few lines:
include:
- component: gitlab.com/<namespace>/osv-scanner/scan@<version>
The component would run the scan, emit the gitlab report (output #1), and expose it as the appropriate dependency_scanning/container_scanning report artifact so it lands in GitLab's security dashboards automatically.
Prior work
I have a working implementation of the output format in #2858 (closed pending this discussion), including unit tests, snapshot tests, and hermetic schema-conformance tests against GitLab's vendored schemas.
Questions for maintainers
- Is a GitLab Security Report output format something the project is interested in taking on?
- Would you also be open to a companion GitLab CI/CD Component (and where should it live — this repo, a sibling repo like
osv-scanner-action, or a new one)?
Happy to adjust the design / scope based on your preferences before re-opening the PR.
cc @G-Rath @another-rex @cuixq
Problem
GitLab's CI/CD has first-class support for ingesting security findings via Security Report artifacts (dependency scanning, container scanning, etc.), which populate the vulnerability and dependency dashboards. Today, consuming osv-scanner results in GitLab requires converting the SARIF output to GitLab's format out-of-band (see #599), which is lossy and fragile.
There's also no first-class GitLab CI integration, whereas osv-scanner offers reusable GitHub Actions workflows (docs,
google/osv-scanner-action).Proposal
1. A native
gitlaboutput format so results can be consumed directly by GitLab:2. A GitLab CI/CD Component (published to the CI/CD Catalog), mirroring the convenience of the reusable GitHub Actions workflows. A user could then add osv-scanner scanning with a few lines:
The component would run the scan, emit the
gitlabreport (output #1), and expose it as the appropriatedependency_scanning/container_scanningreport artifact so it lands in GitLab's security dashboards automatically.Prior work
I have a working implementation of the output format in #2858 (closed pending this discussion), including unit tests, snapshot tests, and hermetic schema-conformance tests against GitLab's vendored schemas.
Questions for maintainers
osv-scanner-action, or a new one)?Happy to adjust the design / scope based on your preferences before re-opening the PR.
cc @G-Rath @another-rex @cuixq