Use variables_override for scheduled scan execution policies

What does this MR do and why?

This MR fixes an error when a SECRET_DETECTION_HISTORIC_SCAN variable value defined at instance level could override the value defined by a scheduled sep job.

This change should also fix similar errors for other variables and for when the variable is defined at project or group level.

In MR !213421 (merged), we fixed a bug that prevented the first scheduled scan execution secret detection jobs from running a historic scan. However it seems that after this change the subsequent scheduled scan execution secret detection jobs could also unintentionally run a historic scans in some cases as when a SECRET_DETECTION_HISTORIC_SCAN is defined as in instance variable with the value true.

This MR fixes this error extending the work we did in This Use variables_override concept for SEP to work with scheduled scan execution policy jobs.

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Enable the feature flag scan_execution_policy_variables_override using the rails console:

Feature.enable(:scan_execution_policy_variables_override)

2. Create a new project.
3. Go to Secure > Policies.
4. Click on New policy
5. Select Scan execution policy.
6. Create a scheduled policy with a secret detection job.

scan_execution_policy:
  - name: SEP
    description: ''
    enabled: true
    rules:
      - type: schedule
        cadence: 0 0 * * *
        branch_type: all
    actions:
      - scan: secret_detection
        template: latest
        variables:
          SECURE_ENABLE_LOCAL_CONFIGURATION: 'false'
    skip_ci:
      allowed: true

7. Go to the Admin Area > Settings > CI/CD > Variables. This step could also be done in Group or Project Settings.
8. Add a variable called SECRET_DETECTION_HISTORIC_SCAN with the value true .
9. Trigger the schedule using the Rails console.

project = Project.second_to_last
schedule = Security::OrchestrationPolicyRuleSchedule.where(project_id: project.id).first
Security::ScanExecutionPolicies::CreatePipelineWorker.new.perform(project.id, 1, schedule.id, 'main')

10. Go back to the project Build > Pipelines
11. Verify that a historical scan was triggered by searching for this output in the secret detection job.

[INFO] [secrets] [2026-03-05T21:45:58Z] ▶ Using git fetch strategy: FetchAll
[WARN] [secrets] [2026-03-05T21:45:58Z] ▶ Fetching all commits - may take time on large repositories

12. Edit the README.md and commit the changes.
13. Trigger another scheduled

project = Project.second_to_last
schedule = Security::OrchestrationPolicyRuleSchedule.where(project_id: project.id).first
Security::ScanExecutionPolicies::CreatePipelineWorker.new.perform(project.id, 1, schedule.id, 'main')

14. Verify that only the new commit was scanned by searching for this output in the secret detection job..

[INFO] [secrets] [2026-03-05T21:48:11Z] ▶ Validating SHA range: 09f87118711a9b3b8f96af463141bfaa6fcb1255..57b83ecb185bfff108dc4c1ccda1294788252403
[INFO] [secrets] [2026-03-05T21:48:11Z] ▶ Validated range 09f87118711a9b3b8f96af463141bfaa6fcb1255..57b83ecb185bfff108dc4c1ccda1294788252403: will scan 1 commits

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.