<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> <!--- Related Zendesk ticket: #[728939](https://gitlab.zendesk.com/agent/tickets/728939) Reported by: Mercedes-Benz Group AG (GitLab Dedicated customer) Reproduced by: Simon Howlett, GitLab Support EMEA ---> ### Summary When a Scan Execution Policy (SEP) or Pipeline Execution Policy (PEP) injects multiple security scanners into a pipeline, and one scanner (e.g. `gemnasium-maven-dependency_scanning`) fails with exit code 1 producing no report artifact, while other scanners (e.g. `secret_detection`) succeed and produce reports — the MR Approval Policy with `fallback_behavior: fail: closed` does **not** block the merge request. The MR remains "Ready to merge" despite having zero dependency scanning coverage. ### Steps to reproduce 1. Create a group with a compliance framework (e.g. id: 1) 2. Create a security policy project linked to the group with the following `policy.yml`: ```yaml --- experiments: ensure_pipeline_policy_pre_succeeds: enabled: true approval_policy: - name: mic_vulnerability_approval_policy enabled: true rules: - type: scan_finding scanners: - dependency_scanning vulnerabilities_allowed: 0 severity_levels: - critical - high vulnerability_states: - new_needs_triage branch_type: default vulnerability_attributes: fix_available: true - type: scan_finding scanners: - sast - secret_detection vulnerabilities_allowed: 0 severity_levels: - critical - high vulnerability_states: - new_needs_triage branch_type: default actions: - type: require_approval approvals_required: 1 role_approvers: - maintainer approval_settings: require_password_to_approve: false fallback_behavior: fail: closed policy_tuning: unblock_rules_using_execution_policies: true scan_execution_policy: - name: enforce-dep-scan enabled: true rules: - type: pipeline branches: - "*" actions: - scan: dependency_scanning variables: AST_ENABLE_MR_PIPELINES: "true" - scan: sast variables: AST_ENABLE_MR_PIPELINES: "true" - scan: secret_detection variables: AST_ENABLE_MR_PIPELINES: "true" policy_scope: compliance_frameworks: - id: 1 ``` 3. Create a test project with the compliance framework applied, simple .gitlab-ci.yml and a working `pom.xml`. ``` <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>test-app</artifactId> <version>1.0.0</version> <properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties> <dependencies> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.14.0</version> </dependency> </dependencies> </project> ``` 4. Update pom.xml in a separate branch with a malfunctioned xml which causes `gemnasium-maven` to fail: ```xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>test-app</artifactId> <version>1.0.0</version> <repositories> <repository> <id>broken-repo</id> <url>https://repo.does-not-exist.invalid/maven2</url> </repository> </repositories> <dependencies> <dependency> <groupId>com.nonexistent</groupId> <artifactId>fake-artifact</artifactId> <version>9.9.9</version> </dependency> </dependencies> </project> ``` 5. Open a merge request targeting the default branch 6. Observe the pipeline — `gemnasium-maven-dependency_scanning` fails with exit code 1, no `gl-dependency-scanning-report.json` produced; `secret_detection` succeeds 7. Observe the MR — it shows **"Ready to merge"** despite the failed dependency scanner ### Example Project Reproduced on a self-managed GitLab 19.0.1-ee instance. Example project not publicly available ### What is the current *bug* behavior? - `gemnasium-maven-dependency_scanning` fails with exit code 1 - No `gl-dependency-scanning-report.json` artifact is produced - Pipeline status: **passed with warnings** (due to `allow_failure: true` hardcoded in the scanner template) - `fallback_behavior: fail: closed` does **not** trigger - MR approval policy reports: "Security policy violations have been resolved" - MR status: **Ready to merge** — with zero dependency scanning coverage Pipeline job output: ``` $ /analyzer run [INFO] [gemnasium-maven] ▶ GitLab gemnasium-maven analyzer v6.6.1 exit status 1 WARNING: gl-dependency-scanning-report.json: no matching files. ERROR: No files to upload ERROR: Job failed: exit code 1 ``` ### What is the expected *correct* behavior? When a scanner configured in a Scan Execution Policy or Pipeline Execution Policy fails and produces no report artifact, `fallback_behavior: fail: closed` should trigger and block the MR with: > "Pipeline configuration error: Security reports required by policy `<policy_name>` could not be found." This correctly occurs when **only** the failing scanner runs. The bug manifests specifically when **multiple scanners run and at least one succeeds** — the policy engine evaluates the successful reports and passes, silently ignoring the missing report from the failed scanner. ### Relevant logs and/or screenshots **Pipeline evidence (from customer):** ```json { "failed_job": { "name": "gemnasium-maven-dependency_scanning", "status": "failed", "allow_failure": true, "error": "exit status 1 — no gl-dependency-scanning-report.json produced", "artifacts_produced": "NONE" }, "security_policy": { "name": "mic_vulnerability_approval_policy", "blocks_merge": false, "reason": "No vulnerability findings to evaluate (no report uploaded)" } } ``` **Confirmed reproduction matrix:** | Configuration | Dependency scan | Other scans | MR blocked? | |---|---|---|---| | SEP, single scanner only | Failed, no report | N/A | ✅ Yes | | SEP, multiple scanners | Failed, no report | Passed | ❌ No (bug) | | PEP, multiple scanners | Failed, no report | Passed | ❌ No (bug) | | SEP + PEP combined | Failed, no report | Passed | ❌ No (bug) | **Toggles tested that do NOT fix the issue:** - `unblock_rules_using_execution_policies: false` — still mergeable - `experiments: ensure_pipeline_policy_pre_exceeds: enabled: true` — still mergeable - Removing `vulnerability_attributes: fix_available: true` — still mergeable - Splitting `dependency_scanning` into its own separate rule — still mergeable ### Workaround The following workaround was confirmed to block the MR when the dependency scanner fails: **Requires both of the following:** 1. Enable **"All security policy pipelines must succeed"** in the project settings (**Settings > Merge requests > All security policy pipelines must succeed**) 2. Use a **Pipeline Execution Policy** (not SEP) and override `allow_failure: false` on `gemnasium-maven-dependency_scanning` in the injected CI file: ```yaml include: - template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml - template: Jobs/SAST.latest.gitlab-ci.yml - template: Jobs/Secret-Detection.latest.gitlab-ci.yml gemnasium-maven-dependency_scanning: allow_failure: false ``` **Limitation:** This workaround requires switching from SEP to PEP for scan injection, and enabling the project-level setting on all affected projects. It does not fix the underlying bug in `fallback_behavior: fail: closed`. ### Output of checks - **GitLab version:** 19.0.1-ee (self-managed, also reported on GitLab Dedicated) - **Offering:** GitLab Dedicated + Self-Managed - **Plan:** Ultimate <!-- If you are reporting a bug on GitLab.com, uncomment below --> <!-- This bug happens on GitLab.com --> <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes The policy engine's `fallback_behavior: fail: closed` logic likely evaluates whether **any** required scan report is present rather than checking that **all** configured scanners produced reports. When at least one scanner succeeds, the fallback is not triggered even if other configured scanners failed with no report. The fix should ensure that `fallback_behavior: fail: closed` triggers independently per scanner rule — if a scanner configured in the policy failed and produced no report, that rule should be treated as a violation regardless of other scanners' outcomes. <!-- If you can, link to the line of code that might be responsible for the problem. --> ### 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. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->