## Summary Rollout for `sbom_scan_malware_findings`, which gates malware findings in the SBOM/CI scan path. The implementation shipped in [!249853](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249853) (merged as `7b9149594d72`, %19.4) for [#612091](https://gitlab.com/gitlab-org/gitlab/-/work_items/612091). The flag was moved to `type: beta` and default-enabled in [!253735](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253735), merged 2026-09-08, 19.4. ## Feature flag | Option | Value | | --- | --- | | Name | `sbom_scan_malware_findings` | | Type | `beta` | | Default enabled | `true` | | Actor | **project** — `Feature.enabled?(:sbom_scan_malware_findings, project)` (`security_report_builder.rb:136`) | | Introduced by | [!249853](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249853) | | Default-enabled by | [!253735](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253735), merged 2026-09-08, 19.4 | | Feature issue | [#612091](https://gitlab.com/gitlab-org/gitlab/-/work_items/612091) | | Milestone | %19.4 | The actor is still a project, so the flag can be turned off for a single project or group if verification turns up a problem, without reverting the default. ## Status: default-enabled in 19.4 `sbom_scan_malware_findings` was moved from `type: wip` to `type: beta` and switched to `default_enabled: true` in [!253735](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253735), merged 2026-09-08. The YAML definition moved from `ee/config/feature_flags/wip/` to `ee/config/feature_flags/beta/` to match. Self-managed and GitLab Dedicated instances get the flag on by default as of 19.4. On GitLab.com, `default_enabled: true` does not override a gate already persisted for an actor, so any project, group or percentage gate set earlier through chatops still wins — GitLab.com state has to be confirmed with `/chatops run feature get sbom_scan_malware_findings` rather than assumed from the default. This issue is now in verification, not enablement: confirm findings behave as expected on production, then remove the flag. ## What changes when it is enabled `SecurityReportBuilder` begins matching SBOM components against `PackageMetadata::MalwareAffectedPackage` in addition to the existing public-advisory matching. Both entry points are covered, since they share the one builder: the `sbom_scans` API path via `ProcessSbomScanService`, and the CycloneDX artifact path via `Ci::JobArtifact#build_security_reports`. Three consequences worth being explicit about before enabling anywhere real: 1. **Vulnerability counts go up, and the new findings are `critical`.** Malware advisories carry no CVSS, so the malware path asserts `critical` rather than deriving severity. Expect this to move critical counts on security dashboards and anything driven off them, such as SLA or policy thresholds. 2. **Findings are additive, not deduplicated.** A package covered by both a public and a malware advisory keeps a finding from each, per the decision in [#594791](https://gitlab.com/gitlab-org/gitlab/-/work_items/594791). Suppressing the malware finding would report `malware = false` on a genuinely malicious package. So for packages like the real `chalk` and `debug` compromises, projects will see two findings, not one. 3. **Only the default branch is in scope.** VAC support for non-default branches is tracked separately in [#612169](https://gitlab.com/gitlab-org/gitlab/-/work_items/612169), and the related UUID gap in [#616781](https://gitlab.com/gitlab-org/gitlab/-/work_items/616781). ## Prerequisites | Requirement | Status | | --- | --- | | Scan-result cache invalidation on malware sync — [#612092](https://gitlab.com/gitlab-org/gitlab/-/work_items/612092) | ✅ merged. Without it a cached result masks the new findings and verification is unreliable | | Advisory data present — `sync_malware_advisories` and `ingest_malware_advisories` | ✅ both default-enabled in %19.3 | | Withdrawn advisories excluded — [#612090](https://gitlab.com/gitlab-org/gitlab/-/work_items/612090) | ✅ merged as [!251666](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251666) | Known and accepted, not blocking: [#616888](https://gitlab.com/gitlab-org/gitlab/-/work_items/616888) — `find_cached_scan` does not apply `not_expired`, so a reused scan can be up to about a day past `EXPIRED_AGE`. Relevant when verifying, because a stale reuse can look like "the flag did nothing". ## The UI flags are separate Enabling this flag makes the findings **exist**. It does not make them visible as malware in the UI. That needs a different set, none of which affect scanning: | Flag | Actor | Surfaces | | --- | --- | --- | | `malicious_package_detection` | root namespace | The malware icon on the vulnerability report | | `malicious_vulnerability_filter_project` | project | The malware filter on the project report | | `malicious_vulnerability_filter_group` | group | The malware filter on the group report | | `sscs_malware_detection` | group | Required alongside the filter flags | The malware **filter** is served by Elasticsearch, so it additionally needs advanced search configured and the vulnerabilities indexed. Without that the filter returns nothing even when the findings exist in Postgres, which is easy to misread as this flag having failed. ## Rollout steps ### Staging - [ ] Pick a test project with known malicious dependencies, clear any cached `SbomScan` for it, and run a dependency scanning pipeline - [ ] Confirm malware findings appear with `critical` severity - [ ] Confirm the public-advisory findings are unchanged and still present alongside them - [ ] Confirm a project with no malicious dependencies sees no new findings and no material change in scan duration ### Production - [ ] Confirm GitLab.com state with `/chatops run feature get sbom_scan_malware_findings`, since a previously persisted gate would override the new default - [ ] Monitor `ProcessSbomScanWorker` error rate and duration, dependency scanning job duration, and vulnerability creation volume - [ ] Hold for a full release cycle before removal, so self-managed sees the same behaviour ### Cleanup - [ ] Remove the flag and `malware_findings_enabled?` from `SecurityReportBuilder`, making the malware matching unconditional - [ ] Delete `ee/config/feature_flags/beta/sbom_scan_malware_findings.yml` - [ ] Add a changelog entry with the removal, since the feature becomes user-visible at that point - [ ] Close this issue ## What to watch - **Scan latency.** The malware match adds one indexed query per SBOM batch. The join is covered by `i_pm_malware_affected_packages_on_purl_type_and_package_name`, so cost scales with batch width rather than the advisory table, but dependency scanning job duration is the metric to confirm that in practice. - **Finding volume.** A sudden spike suggests either a bad advisory batch or a matching bug, not genuine malware. Malicious packages are typosquats with near-zero adoption, so real match rates should be low. - **Support signals** about unexpected `critical` findings, or about two findings appearing for one package — the latter is expected per [#594791](https://gitlab.com/gitlab-org/gitlab/-/work_items/594791) and should be answered, not treated as a bug. ## Rollback `/chatops run feature set sbom_scan_malware_findings false` stops new malware findings immediately. Findings already created are **not** removed by disabling the flag. If they need to be withdrawn, that is a separate data cleanup — resolving vulnerabilities for retracted advisories is [#612099](https://gitlab.com/gitlab-org/gitlab/-/work_items/612099), deferred to post-GA. ## Acceptance criteria - [ ] Verified on staging against a project with real malicious dependencies. - [ ] Rolled out to 100% on production and stable for a release cycle. - [ ] Flag and its conditional removed from the codebase. - [ ] Any problems found during rollout recorded here with links. Parent epic: https://gitlab.com/groups/gitlab-org/-/epics/21156