### Summary Merge Request Approval Policy rules that use `vulnerability_attributes.fix_available: true` do not exclude container_scanning findings that have no upstream fix, when the scanner emits a non-empty **placeholder** string in the `solution` field (for example, Trivy writes the literal `"No solution provided"` for OS-level kernel CVEs against `linux-libc-dev`). The `Security::Finding.fix_available` ActiveRecord scope treats **any** non-empty `solution` string as "fix available". A placeholder like `"No solution provided"` is non-empty, so the scope classifies the finding as fix-available and it stays inside the policy's evaluation set — the opposite of the intended filter semantics. As a result, MRs on affected projects are blocked by findings that have no actual remediation. The `fix_available` filter was introduced in %"16.7" via #424963 to solve exactly this class of problem ("do not block MRs when there is no fix available"). The current implementation is defeated whenever a scanner reports a non-null sentinel string instead of an actual remediation, which is the default Trivy behaviour for CVEs with no upstream fix. ### Steps to reproduce 1. Configure container scanning against an image whose OS packages have CVEs with no upstream fix. `linux-libc-dev` in a Debian/Ubuntu base image is a reliable reproducer. 2. Create (or reuse) a scan result / MR approval policy on the default branch with a rule of the form: ```yaml rules: - type: scan_finding scanners: - container_scanning - dependency_scanning vulnerabilities_allowed: 0 severity_levels: - critical - high vulnerability_states: - new_needs_triage branch_type: default vulnerability_attributes: fix_available: true ``` 3. Open an MR that surfaces the container_scanning findings. 4. Query the pipeline findings via GraphQL to inspect the `solution` field: ```graphql query { project(fullPath: "<project>") { pipeline(iid: <pipeline_iid>) { securityReportFindings(reportType: ["container_scanning"]) { nodes { uuid solution vulnerability { id } } } } } } ``` 5. Observe that `solution` is the literal string `"No solution provided"` (non-empty, non-null). 6. Observe that the policy blocks the MR because `fix_available: true` did **not** exclude these findings, even though there is no remediation available. ### What is the current *bug* behavior? The `fix_available` scope evaluates to true whenever `finding_data->>'solution'` is a non-empty string, regardless of whether that string represents an actual remediation or a scanner-generated placeholder. Concretely, for the reproduction above: ``` finding_data.remediation_byte_offsets = [] → first clause: 0 > 0 = false finding_data.solution = "No solution provided" → second clause: COALESCE(...) <> '' = true fix_available? == true (finding is retained by fix_available: true) ``` Findings that objectively have no fix are treated as having one, and the policy filter designed to exclude them keeps them in scope. MRs remain blocked with no legitimate remediation path — dismissal per-finding via `securityFindingDismiss` works, but does not scale. Current scope in [`ee/app/models/security/finding.rb#L172-L177`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/security/finding.rb#L172-L177): ```ruby scope :fix_available, -> do where( "jsonb_array_length(finding_data -> 'remediation_byte_offsets')::bigint > 0 OR COALESCE((finding_data->>'solution')::text, '') <> ''" ) end ``` ### What is the expected *correct* behavior? A finding should only be classified as "fix available" when there is a real, actionable remediation: - structured remediation data present (`remediation_byte_offsets` non-empty), **or** - a `solution` field that is non-empty **and** does not match a known "no fix" sentinel string produced by supported scanners. Equivalently: placeholder strings such as Trivy's `"No solution provided"` should be normalised to null (or otherwise ignored) so they don't defeat the filter. With that in place, the reproduction above should result in the policy correctly excluding the `linux-libc-dev` findings from evaluation, and the MR should not require approval on their account. ### Relevant logs and/or screenshots Example pipeline findings from a real customer reproduction (UUIDs anonymised are OS-level kernel CVEs against `linux-libc-dev@6.8.0-137.137`): ``` UUID: 1d35fc56-62e3-5a5e-ad4e-85a733d6be67 Solution: "No solution provided" UUID: cadaf2df-6542-5422-b320-92fe1877f57a Solution: "No solution provided" UUID: 049d4b20-6e01-59ec-a872-26861836d784 Solution: "No solution provided" ``` All 15 blocking findings on the affected MR share the identical `finding_data.solution` string `"No solution provided"`. Each has `vulnerability: null` in the GraphQL response (they are pipeline-scoped `Security::Finding` records; no `Vulnerability` row exists because these have not been ingested from a default-branch pipeline). Both facts follow directly from the current data model, but they compound the impact: the policy filter retains them, and there is no bulk dismissal path at project level. ### Output of checks Reproducible on GitLab Dedicated 18.11. The `fix_available` scope on `master` (as of this filing) is unchanged from the implementation that landed with #424963 in %"16.7", so the behaviour is expected to reproduce on all GitLab.com, self-managed, and Dedicated versions from %"16.7" onwards. ### Possible fixes Two viable directions; the second is the customer's preferred framing: 1. **Normalise scanner-emitted placeholders to null before the scope evaluates them.** Maintain a small list of known sentinel strings (`"No solution provided"`, `"No remediation available"`, and any other scanner-specific equivalents) and treat them as absent. Preferable if we want to keep the current scope shape and not couple policy evaluation to remediation structure. 2. **Only consider `fix_available: true` when structured remediation data exists.** Drop the `solution`-string clause from the `fix_available` scope entirely, so it becomes: ```ruby scope :fix_available, -> do where("jsonb_array_length(finding_data -> 'remediation_byte_offsets')::bigint > 0") end ``` This is the tightest contract and matches user expectation ("fix available" = "we have a concrete remediation we can apply"). It does regress the original #424963 intent for scanners that populate `solution` but not `remediation_byte_offsets` — that behaviour needs a design call. Either approach should be paired with a scanner-side clarification (composition analysis / Trivy integration): scanners should emit `null` for `solution` when there is no upstream fix, not a human-readable placeholder. Fixing this in the scanner alone is insufficient because prior findings ingested with the placeholder would remain in the DB; fixing this in the policy scope is necessary for correctness across the installed base. Reference: the closely related work in #584704 (atomic per-scanner rule criteria, delivered in %"18.11") gives users a partial workaround — they can now split the rule so `fix_available: true` applies only to `dependency_scanning` and container_scanning is handled without it. That workaround exists and is being used, but does not address the underlying scope bug. ### Impact - Any customer using MR approval policies with `fix_available: true` and container scanning against a base image with unfixed OS-level CVEs is affected. - On a large customer configuration (~4,600 projects, ~3,000 developers under one policy), the effect is that MRs on affected projects are blocked with no scalable remediation path other than per-finding dismissal via `securityFindingDismiss`. - Origin discussion for the `fix_available` filter: #424963 (closed with the current implementation). - Delivery vehicle for the per-scanner workaround: #584704 (closed in %"18.11"). ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. /cc @alan @nilieskou