## Overview Enable direct upload of SARIF 2.1.0 reports as a first-class artifact format in GitLab, moving toward standardized security report handling alongside CycloneDX SBOMs. ## Spike Outcomes The spike ([!225747](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/225747)) validated that SARIF uploads are feasible. Key findings: - SARIF 2.1.0 schema is compatible with our security scanning workflow - Parser and validator foundation established ([!227875](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/227875)) - PoC demonstrates successful integration with existing vulnerability correlation ## Core Questions - Details field mapping: How to handle SARIF's generic details field vs. our structured data - Identifier stability: Ensure SARIF identifiers remain stable and ordered for deduplication - Suppression handling: Reconcile SARIF suppression model with our vulnerability_flags approach - Severity alignment: Map SARIF severity levels to our vulnerability severity scale ## Next Steps ### Completed * %18.11 ~database ~backend Register sarif as a new artifact and report type, add `plan_limits` migration, CI YAML entry, JSON schema validator, SARIF 2.1.0 parser: * !227968 - artifact type registration + plan_limits migration * !227970 - schema validator, location class, parser, parser registry, ingestion wiring, vulnerability dashboard and pipeline security tab * %18.11 ~"feature flag" ~documentation https://gitlab.com/gitlab-org/gitlab/-/merge_requests/230156+ * %"19.0" ~frontend ~backend MR security diff widget * SARIF findings do not appear in the MR widget. Requires five changes: add `sarif` to `ALLOWED_REPORT_TYPES`, add `sarif` to `EE_REPORT_FILE_TYPES`, add `MergeRequest#has_sarif_reports?` + `#compare_sarif_reports`, a new route, and a controller action. ### In progress * %"19.0" ~backend https://gitlab.com/gitlab-org/gitlab/-/merge_requests/230137+ * ~backend Security Policies * approval/scan result policies work automatically. Pipeline execution policy enforcement has a gap: `PolicyRuleEvaluationService#extract_scanners` falls back to `PIPELINE_SCAN_TYPES` for "all scanners" rules, which excludes `sarif`. Fix: change that fallback to `ApprovalProjectRule::SUPPORTED_SCANNERS`. Owned by ~"group::security policies". * ~backend Vulnerability Management Policy * no_longer_detected rules work at runtime but the policy rule JSON schema (`vulnerability_management_policy_rule_content.json`) doesn't list sarif in the scanners enum, so explicit scanners: [sarif] policies fail validation. One-line fix. * ~documentation SARIF Artifact upload compatibility and field mappings ### Non-blocking follow-up * ~frontend ~backend Ingestion health visibility * SARIF findings without a stable physical location are silently dropped. When a significant proportion is filtered out, the scan should surface a warning in the scanner status / Profiles UX view rather than silently succeeding. Extend the existing Security::Scan status model rather than new UX surface (SRM Profiles UX). * ~backend Vulnerability correlation/deduplication alignment * cross-report-type deduplication with existing SAST/secret-detection findings. See (see https://gitlab.com/gitlab-org/gitlab/-/work_items/592410+)