Thanks for updating the MR @arfedoro! 🙇

LGTM!

Hi @alipniagov, could you please do the backend maintainer review?

What does this MR do?

Removes the security_policies_split_view feature flag from backend code and deletes the flag definition file, completing the feature flag cleanup.

After this MR, the split view (advanced editor toggle) is always available — gated only by the user preference (policy_advanced_editor). No feature flag check is needed.

Related to #593378

Note: This MR should be merged after !227098 (frontend cleanup).

Changes

Source files (4 files)

Test files (6 files)

• Removed stub_feature_flags(security_policies_split_view: ...) from helper spec and all 5 feature specs

MR acceptance checklist

• RSpec helper spec passes (56 examples, 0 failures)
• Rubocop passes (0 offenses)
• No remaining references to security_policies_split_view in the codebase
• Feature flag YAML definition deleted

Thanks for working on this cleanup @arfedoro!

LGTM! I just left a minor suggestion about removing a method parameter.

It seems that we also need a test review.

Hi @mvaishnao, could you please do the test review?

I believe we can remove the container parameter. WDYT of something like:

===================================================================
diff --git a/ee/app/helpers/ee/security_orchestration_helper.rb b/ee/app/helpers/ee/security_orchestration_helper.rb
--- a/ee/app/helpers/ee/security_orchestration_helper.rb	(revision aafeaa5c9a3773f176349096cf40352caabf82f8)
+++ b/ee/app/helpers/ee/security_orchestration_helper.rb	(date 1773778016280)
@@ -78,7 +78,7 @@
       enabled_experiments: enabled_policy_experiments(container),
       designated_as_csp: container.designated_as_csp?.to_s,
       access_tokens: access_tokens_for_container(container).to_json,
-      policy_editor_enabled: policy_editor_enabled?(container).to_s
+      policy_editor_enabled: policy_editor_enabled?.to_s
     }
 
     if container.is_a?(::Project)
@@ -90,7 +90,7 @@
     end
   end
 
-  def policy_editor_enabled?(_container)
+  def policy_editor_enabled?
     return false unless current_user&.user_preference
 
     current_user.user_preference.policy_advanced_editor

Thanks for the updates @mcavoj!

I am enabling the auto-merge!

What does this MR do and why?

Persist per-project schedules for scan execution policies

Add the security_scan_execution_project_schedules table and ScanExecutionProjectSchedule model to persist per-project random offsets for scheduled scan execution policies.

The RuleScheduleService now creates a project schedule row on every execution (behind the scan_execution_policy_project_schedule_creation feature flag).

References

1. 👉 !227096
2. !227101
3. !227102

Database

.for_rule_schedule

SELECT "security_policies".* FROM "security_policies" WHERE "security_policies"."type" = 1 AND "security_policies"."security_orchestration_policy_configuration_id" = 309 AND "security_policies"."policy_index" = 0

Plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/49791/commands/148219

How to set up and validate locally

1. In rails console enable the feature flag

   Feature.enable(:scan_execution_policy_project_schedule_creation)

2. Create a project with a scan execution policy that runs on schedule

   scan_execution_policy:
     - name: Secrets on schedule
       description: ''
       enabled: true
       actions:
         - scan: secret_detection
           template: latest
           variables:
             SECURE_ENABLE_LOCAL_CONFIGURATION: 'false'
       rules:
         - type: schedule
           cadence: 0 0 1 * *
           branch_type: default
           timezone: Europe/Zurich
       skip_ci:
         allowed: true
   

3. Trigger the schedule pipeline manually via rails console

   schedule = Security::OrchestrationPolicyRuleSchedule.last
   schedule.update_columns(next_run_at: 1.day.ago) && Security::OrchestrationPolicyRuleScheduleWorker.new.perform    

4. Verify that project schedule record was created with schedule.project_schedules
5. Run the schedule again and verify that it doesn't get re-created again

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.

Related to #592731

Hi @mbobin, do you have capacity to review this MR?

Marcos Rocha (538f8bc8) at 17 Mar 14:21

Marcos Rocha (96ab6fdf) at 17 Mar 14:21

... and 1 more commit

Thanks for the updates @Andyschoenen!

backend LGTM!

Hi @mksionek, could you please do the backend maintainer review?

What does this MR do and why?

Background

Scheduled Pipeline Execution Policies (SPEP) allow organizations to enforce scheduled pipelines across all projects in a group. However, customers are hesitant to enable these policies in production because they lack visibility into the potential impact — they need to understand how many pipelines will be triggered, how long each will take, and the overall resource cost.

To address this, we are building a test run feature that lets users validate a policy configuration by triggering a dry-run on a single project before enabling the policy at scale. The test run captures pipeline duration and status, which can then be used to estimate the total impact across all projects in scope.

The backend service for creating and tracking test runs was merged in !222053, and the testRuns query field on SecurityPolicyType was added in !226513. This MR adds the GraphQL mutation to trigger a test run and a top-level query to fetch a single test run by ID, completing the API surface needed by the frontend.

What this MR does

1. PipelineExecutionSchedulePolicyTestRun mutation — Accepts a policy ID and project path, validates the policy is a pipeline_execution_schedule_policy, and delegates to the existing TestRunService to create the pipeline and test run record. Returns the test run and pipeline on success, or an error message on failure.

2. pipelineExecutionSchedulePolicyTestRun query — A top-level query that resolves a single test run by its global ID, authorized via :read_policy_schedule_test_run (requires push access to the security policy project).

3. PolicyScheduleTestRunType — GraphQL type exposing: id, state, started_at, finished_at, duration_seconds, error_message, project, pipeline, and a completed boolean that returns true when the run is in either complete or failed state (i.e., no longer running).

4. completed? model method — Added to ScheduledPipelineExecutionPolicyTestRun so the completed field correctly reflects that a failed run is also "done", not just a successful one.

5. ScheduledPipelineExecutionPolicyTestRunPolicy — DeclarativePolicy class that delegates project-level permissions and adds a custom :read_policy_schedule_test_run ability for policy authors.

Authorization

References

• Issue: #586805
• Test run feature epic: &20526
• SPEP GA release epic: &17875
• Backend MR (test run service): !222053
• testRuns field MR: !226513
• PoC MR: !218585

How to set up and validate locally

1. Enable the feature flag:

   Feature.enable(:spep_test_run)

2. Set up a group with a security policy project and a scheduled pipeline execution policy (see !222053 for detailed setup steps).

3. Trigger a test run via the GraphQL mutation:

   mutation {
     pipelineExecutionSchedulePolicyTestRun(input: {
       policyId: "gid://gitlab/Security::Policy/<POLICY_ID>"
       projectPath: "your-group/your-project"
     }) {
       testRun {
         id
         state
         completed
         durationSeconds
         startedAt
         finishedAt
         errorMessage
         project { fullPath }
         pipeline { id status }
       }
       errors
     }
   }

4. Verify the mutation returns a test run in running state with a pipeline.

5. After the pipeline completes, query the test run by ID:

   query {
     pipelineExecutionSchedulePolicyTestRun(
       id: "gid://gitlab/Security::ScheduledPipelineExecutionPolicyTestRun/<TEST_RUN_ID>"
     ) {
       id
       state
       completed
       durationSeconds
       startedAt
       finishedAt
       errorMessage
     }
   }

6. Verify completed is true and durationSeconds reflects the pipeline duration.

7. Test error cases:

   • Using a non-schedule policy ID → returns "Policy must be a pipeline_execution_schedule_policy" error
   • Using a non-existent policy ID → returns "Policy not found" error
   • Querying without push access to the policy project → returns resource not available error

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.

Related to #586805

What does this MR do and why?

Fixes vulnerability attributes (false_positive and fix_available) not being applied to pre-existing vulnerabilities in merge request approval rules.

The root cause is that vulnerability_attribute_false_positive and vulnerability_attribute_fix_available methods were overridden only in ApprovalProjectRule, while the base ApprovalRuleLike concern returned nil. Since ApprovalMergeRequestRule includes ApprovalRuleLike but did not override these methods, it always returned nil, causing pre-existing vulnerabilities to not be filtered by these attributes during MR approval rule synchronization.

This MR moves the implementation from ApprovalProjectRule up to the shared ApprovalRuleLike concern so that both ApprovalProjectRule and ApprovalMergeRequestRule correctly read vulnerability attributes from the associated scan_result_policy_read.

Changelog: fixed EE: true

References

Closes #585656

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.

Thanks for removing the pending todo @imam_h!

LGTM!

What does this MR do and why?

Fixes vulnerability attributes (false_positive and fix_available) not being applied to pre-existing vulnerabilities in merge request approval rules.

The root cause is that vulnerability_attribute_false_positive and vulnerability_attribute_fix_available methods were overridden only in ApprovalProjectRule, while the base ApprovalRuleLike concern returned nil. Since ApprovalMergeRequestRule includes ApprovalRuleLike but did not override these methods, it always returned nil, causing pre-existing vulnerabilities to not be filtered by these attributes during MR approval rule synchronization.

This MR moves the implementation from ApprovalProjectRule up to the shared ApprovalRuleLike concern so that both ApprovalProjectRule and ApprovalMergeRequestRule correctly read vulnerability attributes from the associated scan_result_policy_read.

Changelog: fixed EE: true

References

Closes #585656

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.

Thanks for answering my questions @mcavoj!

backend LGTM!

What does this MR do and why?

Persist per-project schedules for scan execution policies

Add the security_scan_execution_project_schedules table and ScanExecutionProjectSchedule model to persist per-project random offsets for scheduled scan execution policies.

The RuleScheduleService now creates a project schedule row on every execution (behind the scan_execution_policy_project_schedule_creation feature flag).

References

1. 👉 !227096
2. !227101
3. !227102

Database

.for_rule_schedule

SELECT "security_policies".* FROM "security_policies" WHERE "security_policies"."type" = 1 AND "security_policies"."security_orchestration_policy_configuration_id" = 309 AND "security_policies"."policy_index" = 0

Plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/49791/commands/148219

How to set up and validate locally

1. In rails console enable the feature flag

   Feature.enable(:scan_execution_policy_project_schedule_creation)

2. Create a project with a scan execution policy that runs on schedule

   scan_execution_policy:
     - name: Secrets on schedule
       description: ''
       enabled: true
       actions:
         - scan: secret_detection
           template: latest
           variables:
             SECURE_ENABLE_LOCAL_CONFIGURATION: 'false'
       rules:
         - type: schedule
           cadence: 0 0 1 * *
           branch_type: default
           timezone: Europe/Zurich
       skip_ci:
         allowed: true
   

3. Trigger the schedule pipeline manually via rails console

   schedule = Security::OrchestrationPolicyRuleSchedule.last
   schedule.update_columns(next_run_at: 1.day.ago) && Security::OrchestrationPolicyRuleScheduleWorker.new.perform    

4. Verify that project schedule record was created with schedule.project_schedules
5. Run the schedule again and verify that it doesn't get re-created again

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.

Related to #592731

Thanks @bauerdominic! 🙇

I updated the MR title, description, commit message, and changelog.

Marcos Rocha (8c2395d6) at 17 Mar 13:31

... and 1 more commit

Marcos Rocha (5af69d80) at 17 Mar 13:25

... and 257 more commits

Thanks for the quick answer @bauerdominic! 🙇

I updated the MR according to your patch!

I don't think it's urgent. The related KEV and EPSS feature has not yet been released.

It seems the query worked after a few retries. Also, we only query for CVE enrichments updated in the last hour. I believe that in the worst case, the query would time out during this one hour, and after that, the job will not find recently CVEs anymore and will end without error, since the CVE enrichments are updated only once per day.