Include scheduled pipeline execution policy scans in approval baseline

What does this MR do and why?

ci_and_security_orchestration_sources re-adds security_orchestration_policy (scheduled scan execution policy) to the dangling-source exclusion list, but not its sibling pipeline_execution_policy_schedule (scheduled pipeline execution policy). Approval policies use that set both to pick the target-branch baseline pipeline and to decide whether a finished pipeline should trigger re-evaluation, so a scheduled pipeline execution policy scan is invisible to both: it can't become a baseline, and its completion never re-syncs open MR approvals. A CVE already recorded by a scheduled scan then shows as newly introduced on unrelated MRs.

Fix: add :pipeline_execution_policy_schedule directly to ci_and_security_orchestration_sources.

This also widens two other consumers of the same constant to treat scheduled pipeline execution policy scans like scheduled scan execution policy scans, which is an accepted, deliberate side effect rather than a regression:

  • Project#latest_pipeline_for_ci_and_security_orchestration (SAST/DAST compliance-standards baseline)
  • EE::Gitlab::Ci::ProjectConfig::SecurityPolicyDefault#valid_pipeline_source? (security-policy config resolution)

References

Resolves #607430 (closed)

How to set up and validate locally

  1. Create an approval policy with a scan_finding rule (e.g. dependency_scanning, severity critical/high, vulnerability_states: [new_needs_triage]) on the default branch.
  2. Create a scheduled pipeline execution policy that runs a dependency scan on the default branch.
  3. Trigger the scheduled pipeline execution policy pipeline and let it complete with new findings.
  4. Open an MR targeting the default branch — the newly-recorded findings should no longer be treated as "newly introduced" compared to a stale push pipeline baseline.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Alan (Maciej) Paruszewski

Merge request reports

Loading
Loading