_Filed by GitLab Support from a customer investigation (internal Zendesk ticket 749196). Analysis was AI-assisted and reviewed by the filing engineer. Customer-identifying evidence (project, MRs, pipeline IDs) is available internally via the ticket._ ## Summary When a merge request approval policy (`scan_finding`) selects the target-branch comparison pipeline, two independent behaviours combine to silently exclude scan execution policy (SEP) results and/or compare against the wrong commit: 1. **Crowd-out**: candidate selection takes the 10 newest `ci_sources` pipelines per candidate SHA (`MergeRequest::MAX_CHECKED_PIPELINES_FOR_SECURITY_REPORT_COMPARISON`) and then checks for security reports. On a busy branch with a frequent scheduled pipeline that produces no security reports, the report-free scheduled pipeline runs fill the 10-slot window within hours. The baseline then silently slides from the merge base to `start_sha` or a more recent commit. 2. SEP pipelines are structurally excluded from baseline selection: `security_orchestration_policy` sources pipelines are not evaluated, so SEP-scheduled pipelines can never be the baseline. They only join the comparison via `Security::RelatedPipelinesFinder`'s same-SHA expansion on whichever commit the baseline landed on. Consequently: - When crowd-out moves the baseline off the merge base, the SEP scan on the merge base is lost even though it exists and completed. - Even without crowd-out, a nightly SEP scans exactly one commit per day (the tip at schedule time). On a branch receiving many merges per day, most MRs' merge bases were never SEP-scanned, so the SEP is not evaluated. - `policy_tuning.security_report_time_window` cannot compensate: `find_pipeline_within_time_window` also filters `ci_sources`, so the look-back can never select an SEP pipeline. (Docs gap; see below.) Impact: MRs blocked with "newly detected" findings that the nightly SEP had recorded on the target branch; the security bot's target list showing pipelines from a commit other than the merge base; identical policies behaving differently across projects purely as a function of target-branch pipeline density. Rebasing "fixes" it only by moving the comparison to a fresh push scan. ## Steps to reproduce 1. Ultimate project, MRAP with a `scan_finding` rule (e.g. `new_needs_triage`), SEP with `type: schedule` (daily) running SAST + Dependency Scanning on the default branch. Default branch push pipelines also produce security reports. 2. Add a scheduled pipeline (source `schedule`) on the default branch that runs hourly and produces **no** security report artifacts. 3. Merge a commit; let it be the SEP's scheduled-run commit; wait >10 hours so hourly runs fill the window on it. 4. Open an MR whose merge base is that commit. The bot's target list shows pipelines from a *different* commit (`start_sha` or newer), and the SEP results are absent. 5. Variant (no hourly schedule needed): open an MR whose merge base is any mid-day commit. No SEP pipeline exists for it, so SEP results are absent from the comparison by design. ## Root cause (code, `master`) - `ee/app/models/ee/merge_request.rb` — `target_branch_comparison_pipelines` / `batch_loaded_recent_target_branch_pipelines_for_shas`: LATERAL join per candidate SHA, `source IN (ci_sources)`, `ORDER BY id DESC LIMIT 10` (`MAX_CHECKED_PIPELINES_FOR_SECURITY_REPORT_COMPARISON`). Report presence (`has_security_reports?`, via `latest_scan_finding_comparison_pipeline`) is checked only *after* the limit is applied. - `app/models/concerns/enums/ci/pipeline.rb` — `security_orchestration_policy` is in `dangling_sources`, hence excluded from `ci_sources`. - `ee/app/services/concerns/security/scan_result_policies/related_pipelines.rb` — SEP pipelines only enter via `related_pipeline_sources` (`ci_and_security_orchestration_sources`) in `RelatedPipelinesFinder`, which matches on the **baseline's SHA** (`latest_completed_pipelines_matching_sha`). `find_pipeline_within_time_window` filters `.ci_sources`, so the time window cannot reach SEP pipelines either. ## Proposed fixes 1. Prefer report-carrying pipelines in candidate selection: filter (or rank) by presence of security report artifacts before applying the 10-per-SHA limit, e.g. push the `with_reports` semi-join into the LATERAL query, rather than taking the 10 newest and filtering afterwards. #455760 fixed exactly this class of problem for `license_finding` in 17.5 ("latest 10 pipelines … scheduled pipelines without the scan job"); the `scan_finding` path still has it. 2. Make scheduled SEP results usable beyond their single commit: allow an SEP-scheduled pipeline to serve as (or contribute to) the baseline when its commit is an ancestor of the merge base within a bounded window, or include `security_orchestration_policy` in the `security_report_time_window` look-back. Otherwise a daily SEP on a busy branch is structurally invisible to MRAP for most MRs. 3. Documentation: state explicitly that (a) SEP-scheduled pipelines only count when they share a commit with the selected baseline, and (b) `security_report_time_window` only considers `ci_sources` pipelines and is only consulted when no candidate carries reports at all. Current docs for `security_report_time_window` ("use previously completed security reports") do not mention either restriction (#525509 introduced the feature; docs gap). ## Related - #455760 (closed, 17.5) — identical crowd-out defect fixed for `license_finding` only. Precedent. - #607430 (open) — sibling issue: `pipeline_execution_policy_schedule` source excluded from `ci_and_security_orchestration_sources` entirely. - #525509 (closed, 18.5) — `security_report_time_window` feature; no mention of the `ci_sources` look-back restriction. /cc @gitlab-org/govern/security-policies