### 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 CVEs against packages like `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, which is 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 solutio` is the literal string "No solution provided" 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. Placeholder strings such as Trivy's "No solution provided" could 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. ### Output of checks Reproducible against master. The `fix_available` scope has been unchanged since #424963 landed 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 TBD; but **Reference**: the related work in #584704 (atomic per-scanner rule criteria, delivered in %"18.11") gives users a partial workaround, where they can split the rule so `fix_available: true` applies only to `dependency_scanning` and container_scanning is handled without it. That workaround exists 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 large deployments running a single policy across thousands of projects, 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 for the per-scanner workaround: #584704 (closed in %"18.11"). /cc @alan @nilieskou