# Scheduled pipeline execution policy scan results are ignored by merge request approval policies _The analysis, source tracing, and write-up in this issue were produced with AI assistance and reviewed by the author._ ## Summary Merge request approval policies choose the target-branch comparison baseline from pipelines whose `CI_PIPELINE_SOURCE` is in `Enums::Ci::Pipeline.ci_and_security_orchestration_sources`. That set re-includes one dangling source, `security_orchestration_policy` (scheduled **scan execution** policies), but not its sibling `pipeline_execution_policy_schedule` (scheduled **pipeline execution** policies). So a scheduled pipeline execution policy's scans are ignored by approval policies: they neither trigger re-evaluation when the pipeline completes nor qualify as a comparison baseline. A CVE disclosed against a dependency already on the default branch then shows as "newly introduced" on unrelated MRs, even after a daily policy scan has recorded it on the branch. Expected: a scheduled pipeline execution policy scan on the default branch should count toward approval evaluation, as a scheduled scan execution policy scan already does. ## Steps to reproduce 1. Approval policy on the default branch: `scan_finding` rule with `dependency_scanning`, `severity_levels: [critical, high]`, `vulnerability_states: [new_needs_triage]`. 2. Scheduled **pipeline execution** policy running a dependency scan daily on the default branch. 3. With the default branch quiet, a new CVE is disclosed against a dependency already on it; the next scheduled scan records it (visible in the Vulnerability Report). 4. Open an MR. Its pipeline reports the CVE and the policy blocks it as newly detected — comparing against the last `push` pipeline, not the scheduled scan. ## Observed occurrence `main` was at commit `a220615a` (v1.55.0) with no later commits. `CVE-2026-13149` (brace-expansion) was disclosed against an existing dependency after that commit's original pipeline ran. Sources confirmed via the pipelines API: | Pipeline | Source | Commit | Dependency findings | Used as baseline | |---|---|---|---|---| | `#2674134124` | `push` | `a220615a` | 64 | yes | | `#2716391012` | `pipeline_execution_policy_schedule` | `a220615a` | 74 | no | Same commit; the scheduled re-scan reports 10 more findings only because the advisory database advanced. The policy compares the MR against the 64-finding `push` pipeline instead of the 74-finding scheduled one, so those 10 (including `CVE-2026-13149`) count as new and block the MR — while the project Vulnerability Report already lists `CVE-2026-13149` as present on `main`. A shareable example project is impractical (Ultimate-only feature; depends on real CVE-disclosure timing). #582291 is precedent for accepting this class of bug on production evidence alone. ### Screenshots 1 — MR blocked; comparison target for `main` is `#2674134124`, not the scheduled pipeline. {width=821 height=580} 2a — `#2674134124` (`push`, `a220615a`): 64 dependency findings. {width=752 height=444} 2b — `#2716391012` (`pipeline_execution_policy_schedule`, same commit): 74 dependency findings. {width=728 height=389} 2c — `CVE-2026-13149` present in `#2716391012`'s report. {width=900 height=179} 3 — Project Vulnerability Report: `CVE-2026-13149` still detected on `main`. {width=900 height=317} ## Root cause Code pinned to `master` at `d060f6c0`. In [`enums/ci/pipeline.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/app/models/concerns/enums/ci/pipeline.rb#L78), `ci_sources` excludes every dangling source, and `ci_and_security_orchestration_sources` re-adds only one of them: ```ruby def self.dangling_sources sources.slice( :webide, :parent_pipeline, :ondemand_dast_scan, :ondemand_dast_validation, :security_orchestration_policy, # scheduled scan execution policy :container_registry_push, :duo_workflow, :pipeline_execution_policy_schedule, # scheduled pipeline execution policy :dependency_management_security_update ) end def self.ci_and_security_orchestration_sources ci_sources.merge(sources.slice(:security_orchestration_policy)) # re-adds one of the two end ``` `pipeline_execution_policy_schedule` is never re-added, so it is absent from both approval-policy consumers of this set: - Baseline — [`related_pipelines.rb#L40`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/ee/app/services/concerns/security/scan_result_policies/related_pipelines.rb#L40): `related_pipeline_sources` feeds this set to `Security::RelatedPipelinesFinder`, whose `with_pipeline_source` filter drops the pipeline before SHA matching. - Trigger — [`sync_findings_to_approval_rules_service.rb#L23`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/ee/app/services/security/scan_result_policies/sync_findings_to_approval_rules_service.rb#L23): `sync_scan_finding` returns early unless the finished pipeline's source is in the set. ## Proposed fix The constant is shared, so adding `:pipeline_execution_policy_schedule` to it directly also reaches call sites where the effect is unwanted: | Call site | Effect of the added source | | |---|---|---| | [`related_pipelines.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/ee/app/services/concerns/security/scan_result_policies/related_pipelines.rb#L40) — security baseline | scheduled scan becomes an eligible baseline | wanted (the fix) | | [`sync_findings_to_approval_rules_service.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/ee/app/services/security/scan_result_policies/sync_findings_to_approval_rules_service.rb#L23) — trigger | scheduled completion re-evaluates open MRs | wanted (required) | | [`update_license_approvals_service.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/ee/app/services/security/scan_result_policies/update_license_approvals_service.rb#L149) — license baseline | same for license policies | consistent | | [`project.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/app/models/project.rb#L1754) → SAST/DAST compliance standards | a dependency-only scheduled scan can become the "newest" pipeline these read, flipping "SAST/DAST running" to FAIL | regression | | [`security_policy_default.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/ee/lib/ee/gitlab/ci/project_config/security_policy_default.rb#L69) `valid_pipeline_source?` | may inject scan-execution-policy scans into scheduled pipeline-execution pipelines | needs maintainer review | The compliance regression is concrete: [`sast_service.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/d060f6c0de5ff9bec4cb0dbd6070e48f84268759/ee/app/services/compliance_management/standards/gitlab/sast_service.rb#L11) takes the newest eligible pipeline and checks `job_artifacts.sast.count > 0`; the scheduled pipeline in the reproduction ran only a dependency job, so it would report zero SAST. A dedicated grouping scoped to the approval path avoids both the regression and the config-resolution site: ```ruby def self.ci_security_orchestration_and_scheduled_pep_sources ci_and_security_orchestration_sources.merge(sources.slice(:pipeline_execution_policy_schedule)) end ``` used only in `related_pipelines.rb` (`related_pipeline_sources`), `update_license_approvals_service.rb`, and `sync_findings_to_approval_rules_service.rb` (`sync_scan_finding`). ## Related - #582291 (closed, bug) — compliance controls failing to detect scan-execution-policy scans; same class of bug, different consumer. - #379110 (open) — approvals from pre-existing findings via scheduled scans; targets the pre-existing path, not the `new_needs_triage` comparison here. - !179741 (GA 18.3) — scanners defined by *injected* pipeline execution policies; does not cover scheduled baselines. Scheduled pipeline execution policies are experimental, which may affect triage.