<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=594471) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=594471) </details> <!--IssueSummary end--> ### Summary GitLab customers consume GitLab as a third‑party component and routinely scan GitLab release artifacts (Linux package, Helm chart, container images) with external tools such as Wiz, Trivy, Grype, and Docker Scout. These scanners often report large numbers of vulnerabilities against GitLab images and packages, but there is no authoritative VEX (Vulnerability Exploitability eXchange) data from GitLab that explains which vulnerabilities are actually exploitable in the context of the GitLab build. Customers are asking GitLab to publish OpenVEX‑format VEX documents for GitLab itself, released alongside each GitLab version, so that they can reliably suppress non‑applicable findings and satisfy regulatory and internal compliance requirements. --- ### Problem to solve **Current situation** * When customers scan GitLab images or packages, they commonly see many HIGH and CRITICAL vulnerabilities reported across Rails, frontend, and system libraries, even when known issues in specific components have already been mitigated. * GitLab Support and Product Security can determine that many of these findings are either not exploitable or are mitigated in practice, but this information is not published in a machine‑readable, vendor‑signed form that customers can ingest. * GitLab already has a separate feature request to ingest vendor‑provided VEX (for example CycloneDX VEX) into GitLab dependency scanning for user workloads, but there is no corresponding capability for GitLab to act as a VEX **producer** for its own product artifacts. * In the absence of GitLab‑produced VEX, customers must: * Treat all scanner findings on GitLab artifacts as equally actionable. * Manually triage and justify exceptions in their GRC tooling. * Struggle to provide defensible evidence to auditors and regulators that specific GitLab vulnerabilities are either fixed or not exploitable. **Impact** This gap causes: * Noise and friction in vulnerability management for organizations that treat GitLab as a critical third‑party component. * Difficulty meeting compliance obligations where vendor attestations or VEX documents are considered authoritative (for example regulatory approvals, SOC 2, ISO 27001). * Duplicate effort, as many customers independently request clarification that could be provided once, centrally, via published VEX. **Customer request (generalized)** Customers are requesting that GitLab provide VEX statements, following the OpenVEX specification, for vulnerabilities in **GitLab’s own build**, and that these statements be released alongside each new GitLab version. The goal is to have GitLab act as a first‑party authority on the exploitability and remediation status of vulnerabilities in GitLab artifacts. --- ### Intended users * Security and vulnerability management teams running GitLab self‑managed or consuming GitLab‑provided images. * Compliance and risk officers who must justify risk exceptions for scanner findings on GitLab artifacts. * Platform and operations teams responsible for scanning and approving third‑party software components (including GitLab). --- ### Proposal **High‑level goal** GitLab publishes OpenVEX VEX documents for GitLab release artifacts so that external scanners and GRC tools can consume GitLab’s own vulnerability dispositions. #### Scope At a minimum: * **Artifacts covered** * Omnibus Linux package (self‑managed). * Official GitLab container images (for example `gitlab-ee`, `gitlab/gitlab-ee`). * Helm chart and related images, where applicable. * **Formats and standards** * OpenVEX documents, using the current OpenVEX namespace (for example `https://openvex.dev/ns/v0.2.0`). * Product identifiers based on PURL or other suitable identifiers for the GitLab release artifacts, in line with best practices for OpenVEX and existing SCA tooling. * **VEX content** * For each relevant vulnerability (CVE, GHSA, etc.) affecting components bundled with GitLab: * `status` in {`not_affected`, `affected`, `fixed`, `under_investigation`}. * `justification` where status is `not_affected` (for example `vulnerable_code_not_in_execute_path`, `component_not_present`, `vulnerable_code_cannot_be_controlled_by_adversary`). * Optional `status_notes` and `action_statement` where additional context is needed. * Versioning of VEX documents so that new analysis can update the same vulnerability across multiple GitLab versions over time. #### Delivery model * **Where to publish** * Attach VEX documents as release assets (for example in the GitLab release pages or a dedicated `security.gitlab.com` location). * Optionally, publish VEX as OCI attestations attached to GitLab images (for example using cosign `--predicate … --type openvex`), to align with emerging industry practice. * **How customers consume** * Customers download or automatically discover VEX documents for the specific GitLab versions they deploy. * External scanners (Wiz, Trivy, Grype, Docker Scout, etc.) ingest OpenVEX and: * Suppress vulnerabilities marked `not_affected` or `fixed`. * Highlight vulnerabilities marked `affected` or `under_investigation` as higher priority. * GRC tools import the same VEX as authoritative vendor attestations for GitLab. #### Relationship to existing work * Existing work around VEX ingestion in GitLab dependency scanning covers GitLab as a **consumer** of third‑party VEX for user workloads. * This proposal covers GitLab as a **producer** of VEX for GitLab’s own release artifacts, to help customers scan GitLab itself as a dependency. * Both features are complementary and can share common libraries, standards, and documentation for VEX handling. --- ### Further details and examples **Representative customer workflow** 1. A customer scans a GitLab release image or package with their preferred SCA tool. 2. The scanner reports a long list of vulnerabilities across Rails, Node.js, and system libraries. 3. The customer fetches GitLab’s OpenVEX document for the exact image or package they are running. 4. The scanner applies GitLab’s VEX to: * Suppress vulnerabilities where GitLab has determined they are not exploitable in the GitLab context. * Highlight vulnerabilities still under investigation or where a fix is pending. 5. The customer: * Attaches GitLab’s VEX document and resulting filtered scan report to internal or external audits. * Stores VEX in their internal GRC system as vendor attestation for GitLab. **Internal‑facing notes (not required to expose in UI)** * This work would likely involve collaboration between: * Product Security / Security Engineering (to determine vulnerability dispositions and justifications). * Release and distribution teams (to integrate VEX generation into existing pipelines). * Composition Analysis / SCA teams (to ensure identifiers and formats are compatible with common scanners). --- ### Acceptance criteria * For at least one supported GitLab major/minor series (for example 18.9 and later), GitLab publishes OpenVEX VEX documents that: * Cover omnibus Linux packages and official GitLab images. * Use stable product identifiers (for example PURLs) that scanners can match against. * Include `not_affected` / `fixed` statements for vulnerabilities where GitLab has determined non‑exploitability or remediation in the GitLab context. * Publication location and format are documented in GitLab’s public documentation, including: * How to locate VEX for a given GitLab version and artifact. * How to use GitLab VEX with common scanners (for example Trivy, Grype, Wiz). * Security and Product Security teams agree on an internal process to: * Add new statements when new vulnerabilities are discovered or triaged. * Update statements when status changes (for example `under_investigation` → `fixed`). * Documentation clearly distinguishes: * GitLab as a VEX consumer for user workloads (existing work). * GitLab as a VEX producer for GitLab release artifacts (this issue). --- ### Permissions and security * VEX documents are public but must be treated as security‑sensitive artifacts: * They should be signed or otherwise integrity‑protected. * Generation and updates should be auditable and traceable to GitLab Security processes. * No new code‑execution paths are introduced; VEX generation and publication should reuse existing release and security pipelines wherever possible.