Scan execution policies

{{< details >}}

• Tier: Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

{{< history >}}

• Support for custom CI/CD variables in the scan execution policies editor introduced in GitLab 16.2.
• Enforcement of scan execution policies on projects with an existing GitLab CI/CD configuration introduced in GitLab 16.2 with a flag named scan_execution_policy_pipelines. Feature flag scan_execution_policy_pipelines removed in GitLab 16.5.
• Overriding predefined variables in scan execution policies introduced in GitLab 16.10 with a flag named allow_restricted_variables_at_policy_level. Enabled by default. Feature flag allow_restricted_variables_at_policy_level removed in GitLab 17.5.

{{< /history >}}

Scan execution policies enforce GitLab security scans based on the default or latest security CI/CD templates. You can deploy scan execution policies as part of the pipeline or on a specified schedule.

Scan execution policies enforce security scans across all projects that are linked to the security policy project. For projects without a .gitlab-ci.yml file, or projects where AutoDevOps is disabled, security policies create the .gitlab-ci.yml file implicitly. The .gitlab-ci.yml file ensures policies that run secret detection, static analysis, or other scanners that do not require a build in the project can always run and be enforced.

Both scan execution policies and pipeline execution policies can configure GitLab security scans across multiple projects to manage security and compliance. Scan execution policies are faster to configure, but are not customizable. If any of the following cases are true, use pipeline execution policies instead:

• You require advanced configuration settings.
• You want to enforce custom CI/CD jobs or scripts.
• You want to enable third-party security scans through an enforced CI/CD job.

Create a scan execution policy

To create a scan execution policy, you can use any of the following resources:

• <i class="fa-youtube-play" aria-hidden="true"></i> For a video walkthrough, see How to set up Security Scan Policies in GitLab.
• <i class="fa-youtube-play" aria-hidden="true"></i> Learn more about enforcing scan execution policies on projects with no GitLab CI/CD configuration.
• For instructions on how to create scan execution policies, see tutorial: set up a scan execution policy

Restrictions

• You can assign a maximum of five rules to each policy.
• You can assign a maximum of five scan execution policies to each security policy project.
• Local project YAML files cannot override scan execution policies. Scan execution policies take precedence over any configurations defined for a pipeline, even if you use the same job name in your project's CI/CD configuration.
• Scheduled policies (type: schedule) execute according to their scheduled cadence only. Updating a policy does not trigger an immediate scan.
• Policy updates that you make directly to the YAML configuration files (with a commit or push instead of in the policy editor) can take up to 10 minutes to propagate through the system. (See issue 512615 for proposed changes to this limitation.)

Job stages

DAST scans always run in the dast stage. If the dast stage does not exist, then GitLab injects a dast stage at the end of the pipeline.

Policy jobs for all other scans, run in the test stage of the pipeline. If you remove the test stage from the default pipeline, jobs run in the scan-policies stage instead according to these rules:

• If the scan-policies stage doesn't already exist, GitLab injects the stage into the CI/CD pipeline at evaluation time.
• If the build stage exists, GitLab injects scan-policies immediately after the build stage.
• If the build stage does not exist, GitLab injects scan-policies at the beginning of the pipeline.

To avoid job name conflicts, a hyphen and a number are appended to the job name. Each number is a unique value for each policy action. For example, secret-detection becomes secret-detection-1.

Scan execution policy editor

{{< history >}}

• Merge Request Security Template:
  • Introduced in GitLab 18.2 with a flag named flexible_scan_execution. Disabled by default.
  • Enabled on GitLab.com, GitLab Self-Managed, and GitLab Dedicated in GitLab 18.3.
  • Generally available in GitLab 18.4. Feature flag flexible_scan_execution removed.

{{< /history >}}

Use the scan execution policy editor to create or edit a scan execution policy.

Prerequisites:

• By default, only group, subgroup, or project Owners have the permissions required to create or assign a security policy project. Alternatively, you can create a custom role with the permission to manage security policy links.

When you create your first scan execution policies, choose from these templates for common use cases:

• Merge Request Security
  • Use case: You want security scans to run only when merge requests are created, not on every commit.
  • When to use: For projects using merge request pipelines that need security scans to run on source branches targeting default or protected branches.
  • Best for: Aligning with merge request approval policies and reducing infrastructure costs by avoiding scans on every branch.
  • Pipeline sources: Primarily merge request pipelines.
• Scheduled Scanning
  • Use case: You want security scans to run automatically on a schedule (like daily or weekly) regardless of code changes.
  • When to use: For security scanning on a regular cadence, independent of development activity.
  • Best for: Compliance requirements, baseline security monitoring, or projects with infrequent commits.
  • Pipeline sources: Scheduled pipelines.
• Release Security
  • Use case: You want security scans to run on all changes to your main or release branches.
  • When to use: For projects that need comprehensive scanning before releases, or on protected branches.
  • Best for: Release-gated workflows, production deployments, or high-security environments.
  • Pipeline sources: Push pipelines to protected branches, release pipelines.

If the available template do not meet your needs, or you require more customized scan execution policies, you can:

• Select the Custom option and create your own scan execution policy with custom requirements.
• Access more customizable options for security scan and CI enforcement using pipeline execution policies.

Once your policy is complete, save the policy by selecting Configure with a merge request at the bottom of the editor. You are redirected to the merge request on the project's configured security policy project. If a security policy project is not linked to your project, GitLab automatically creates one. You can remove existing policies from the editor interface by selecting Delete policy at the bottom of the editor. This action creates a merge request to remove the policy from your policy.yml file.

Most policy changes take effect as soon as the merge request is merged. Any changes committed directly to the default branch instead of a merge request require up to 10 minutes before the policy changes take effect.

[!note] For DAST execution policies, the way you apply site and scanner profiles in the rule mode editor depends on where the policy is defined:

• For policies in projects, in the rule mode editor, choose from a list of profiles that are already defined in the project.
• For policies in groups, you must type in the names of the profiles to use. To prevent pipeline errors, profiles with matching names must exist in all of the group's projects.

Scan execution policies schema

A YAML configuration with scan execution policies consists of an array of objects matching the scan execution policy schema. Objects are nested under the scan_execution_policy key. You can configure a maximum of five policies under the scan_execution_policy key. Any other policies configured after the first five are not applied.

When you save a new policy, GitLab validates the policy's contents against this JSON schema. If you're not familiar with JSON schemas, the following sections and tables provide an alternative.

Scan execution policy schema

{{< history >}}

• Limit of actions per policy introduced in GitLab 17.4 with flags named scan_execution_policy_action_limit (for projects) and scan_execution_policy_action_limit_group (for groups). Disabled by default.
• Limit of actions per policy generally available in GitLab 18.0. Feature flags scan_execution_policy_action_limit (for projects) and scan_execution_policy_action_limit_group (for groups) removed.

{{< /history >}}

skip_ci type

{{< history >}}

• Introduced in GitLab 17.9.

{{< /history >}}

Scan execution policies offer control over who can use the [skip ci] directive. You can specify certain users or service accounts that are allowed to use [skip ci] while still ensuring critical security and compliance checks are performed.

Use the skip_ci keyword to specify whether users are allowed to apply the skip_ci directive to skip the pipelines. When the keyword is not specified, the skip_ci directive is ignored, preventing all users from bypassing the pipeline execution policies.

[!note] Scan execution policies that have the rule type schedule always ignore the skip_ci option. Scheduled scans run at their configured times regardless of whether [skip ci] (or any of its variations) appear in the last commit message. This ensures that security scans occur on a predictable schedule even when CI/CD pipelines are otherwise skipped.

no_pipeline type

Scan execution policies offer control over who can use the [no_pipeline] directive. You can specify certain users or service accounts that are allowed to use [no_pipeline] while still ensuring critical security and compliance checks are performed.

Use the no_pipeline keyword to specify whether users are allowed to apply the no_pipeline directive to not create pipeline on a push. When the keyword is not specified, the no_pipeline directive is ignored, preventing all users from bypassing the pipeline execution policies.

[!note] Scan execution policies that have the rule type schedule always ignore the no_pipeline option. Scheduled scans run at their configured times regardless of whether [no_pipeline] (or any of its variations) appear in the last commit message. This ensures that security scans occur on a predictable schedule even when CI/CD pipelines are not created.

pipeline rule type

{{< history >}}

• The branch_type field:
  • Introduced in GitLab 16.1 with a flag named security_policies_branch_type.
  • Generally available in GitLab 16.2. Feature flag security_policies_branch_type removed.
• The branch_exceptions field:
  • Introduced in GitLab 16.3 with a flag named security_policies_branch_exceptions.
  • Generally available in GitLab 16.5. Feature flag security_policies_branch_exceptions removed.
• The pipeline_sources field and the branch_type options target_default and target_protected:
  • Introduced in GitLab 18.2 with a flag named flexible_scan_execution.
  • Enabled on GitLab.com, GitLab Self-Managed, and GitLab Dedicated in GitLab 18.3.
  • Generally available in GitLab 18.4. Feature flag flexible_scan_execution removed.

{{< /history >}}

This rule enforces the defined actions whenever the pipeline runs for a selected branch.

1. You must specify either branches or branch_type, but not both.
2. Some options are only available with the flexible_scan_execution feature flag enabled. See the history for details.
3. When the branch_type options target_default or target_protected are specified, the pipeline_sources field supports only the merge_request_event and push fields.

schedule rule type

{{< history >}}

• New branch_type field:
  • Introduced in GitLab 16.1 with a flag named security_policies_branch_type.
  • Generally available in GitLab 16.2. Feature flag removed.
• New branch_exceptions field:
  • Introduced in GitLab 16.3 with a flag named security_policies_branch_exceptions.
  • Generally available in GitLab 16.5. Feature flag removed.
• New scan_execution_pipeline_worker worker to scheduled scans to create pipelines:
  • Introduced in GitLab 16.11 with a flag.
  • Enabled on GitLab.com in GitLab 17.5.
  • Generally available in GitLab 17.6. Feature flag scan_execution_pipeline_worker removed.
• New application setting security_policy_scheduled_scans_max_concurrency:
  • Introduced in GitLab 17.1. The concurrency limit applies when both the scan_execution_pipeline_worker and scan_execution_pipeline_concurrency_control are enabled.
  • Removed a new application setting security_policy_scheduled_scans_max_concurrency in GitLab 17.11.
• Concurrency limit for scan execution scheduled jobs:
  • Introduced in GitLab 17.3 with a flag named scan_execution_pipeline_concurrency_control.
  • Generally available in GitLab 17.9. Feature flag scan_execution_pipeline_concurrency_control removed.

{{< /history >}}

[!warning] In GitLab 16.1 and earlier, you should not use direct transfer with scheduled scan execution policies. If you must use direct transfer, first upgrade to GitLab 16.2 and ensure security policy bots are enabled in the projects you are enforcing.

Use the schedule rule type to run security scanners on a schedule.

A scheduled pipeline:

• Runs only the scanners defined in the policy, not the jobs defined in the project's .gitlab-ci.yml file.
• Runs according to the schedule defined in the cadence field.
• Runs under a security_policy_bot user account in the project, with the Guest role and permissions to create pipelines and read the repository's content from a CI/CD job. This account is created when the policy is linked to a group or project.
• On GitLab.com, only the first 10 schedule rules in a scan execution policy are enforced. Rules that exceed the limit have no effect.

1. You must specify only one of branches, branch_type, or agents.

Cadence

Use the cadence field to schedule when you want the policy's actions to run. The cadence field uses cron syntax, but with some restrictions:

• Only the following types of cron syntax are supported:
  • A daily cadence of once per hour around specified time, for example: 0 18 * * *
  • A weekly cadence of once per week on a specified day and around specified time, for example: 0 13 * * 0
• Use of the comma (,), hyphens (-), or step operators (/) are not supported for minutes and hours. Any scheduled pipeline using these characters is skipped.

Consider the following when choosing a value for the cadence field:

• Timing is based on UTC for GitLab.com and GitLab Dedicated, and on the GitLab host's system time for GitLab Self-Managed. When testing new policies, pipelines might appear to run at incorrect times because they are scheduled in your server's time zone, not your local time zone.
• A scheduled pipeline doesn't start until the required resources become available to create it. In other words, the pipeline might not begin precisely at the timing specified in the policy.

When using the schedule rule type with the agents field:

• The GitLab agent for Kubernetes checks every 30 seconds to see if there is an applicable policy. When the agent finds a policy, the scans execute according to the defined cadence.
• The cron expression is evaluated using the system time of the Kubernetes agent pod.

When using the schedule rule type with the branches field:

• The cron worker runs on 15 minute intervals and starts any pipelines that were scheduled to run during the previous 15 minutes. Therefore, scheduled pipelines can run with an offset of up to 15 minutes.
• If a policy is enforced on a large number of projects or branches, the policy is processed in batches, and can take some time to create all pipelines.

agent schema

Use this schema to define agents objects in the schedule rule type.

agent example

- name: Enforce container scanning in cluster connected through my-gitlab-agent for default and kube-system namespaces
  enabled: true
  rules:
  - type: schedule
    cadence: '0 10 * * *'
    agents:
      <agent-name>:
        namespaces:
        - 'default'
        - 'kube-system'
  actions:
  - scan: container_scanning

The keys for a schedule rule are:

• cadence (required): a Cron expression for when the scans are run.
• agents:<agent-name> (required): The name of the agent to use for scanning.
• agents:<agent-name>:namespaces (optional): The Kubernetes namespaces to scan. If omitted, all namespaces are scanned.

time_window schema

Define how scheduled scans are distributed over time with the time_window object in the schedule rule type. You can configure time_window only in YAML mode of the policy editor.

time_window example

- name: Enforce container scanning with a time window of 1 hour
  enabled: true
  rules:
  - type: schedule
    cadence: '0 10 * * *'
    time_window:
      value: 3600
      distribution: random
  actions:
  - scan: container_scanning

Optimize scheduled pipelines for projects at scale

When a policy enforces scheduled pipelines across multiple projects and branches, the pipelines run simultaneously. The first execution of a scheduled pipeline in each project creates a security bot user responsible for executing the schedules for that project.

To optimize performance for projects at scale:

• Roll out scheduled scan execution policies gradually, starting with a subset of projects. You can leverage security policy scopes to target specific groups, projects, or projects containing a given compliance framework label.
• You can configure the policy to run the schedules on runners with a specified tag. Consider setting up a dedicated runner in each project to handle schedules enforced from a policy to reduce impact to other runners.
• Test your implementation in a staging or lower environment before deploying to production. Monitor performance and adjust your rollout plan based on results.

Configuring the maximum scheduling timespan for scheduled scan execution policies

Scheduled scan execution policies support monthly scheduling using the cadence field with cron expressions. You can configure the time_window up to 2629746 seconds (approximately 30 days) to randomly distribute scans within that period.

For example, to schedule scans monthly with a 30-day distribution window:

rules:
  - type: schedule
    cadence: '0 0 1 * *'  # Run on the first day of each month
    time_window:
      value: 2592000  # 30 days in seconds
      distribution: random

Understanding scheduled scans during instance downtimes

Scheduled scans keep track of their next execution time. After a successful scan, the system updates when the next scan should run. If the GitLab instance is unavailable during a scheduled scan time (due to maintenance, outage, or restart), the system identifies scans that should have already executed but haven't, and creates pipelines when the instance becomes available.

Deleting projects with scheduled scans

When you delete a project, all associated scheduled scans are also deleted. No pipelines run for deleted projects.

Canceling a running scheduled scan

To cancel a scheduled scan, you have two options:

• Cancel individual pipelines: If you have the necessary permissions to cancel jobs in the project, you can cancel running pipelines directly from the pipeline view.
• Disable the policy: Set enabled: false in the policy editor to disable the scan execution policy. Scans that are already running or scheduled to run within the next 15 minutes (approximately) might still execute.

Recommendations for large-scale deployments

When you deploy scheduled scan execution policies across many projects, consider the following recommendations:

• Use gradual rollouts: Start with a small subset of projects and gradually add more projects. Use compliance framework labels to scope policies to specific groups of projects.
• Configure time_window: Always set the time_window parameter in your scheduled policies. Without it, all pipelines are scheduled for the same time, which can cause performance issues and resource contention.
• Test in staging: Validate your policy configuration in a staging environment or lower before deploying to production. Monitor performance and adjust based on results.
• Consider runner capacity: The impact on runners depends on your policy configuration, runner availability, and GitLab instance deployment. Configure policies to use runners with specific tags to distribute load.

For more information on optimizing scheduled scans, see optimize scheduled pipelines for projects at scale.

Concurrency control

GitLab applies concurrency control when you set the time_window property.

The concurrency control distributes the scheduled pipelines according to the time_window settings defined in the policy.

scan action type

{{< history >}}

• Scan Execution Policies variable precedence:
  • Changed in GitLab 16.7 with a flag named security_policies_variables_precedence. Enabled by default.
  • Generally available in GitLab 16.8. Feature flag security_policies_variables_precedence removed.
• Selection of security templates for given action:
  • Introduced for projects in GitLab 17.1 with feature flag named scan_execution_policies_with_latest_templates. Disabled by default.
  • Introduced for groups in GitLab 17.2 with feature flag named scan_execution_policies_with_latest_templates_group. Disabled by default.
  • Enabled on GitLab Self-Managed, and GitLab Dedicated in GitLab 17.2.
  • Generally available in GitLab 17.3. Feature flags scan_execution_policies_with_latest_templates and scan_execution_policies_with_latest_templates_group removed.

{{< /history >}}

This action executes the selected scan with additional parameters when conditions for at least one rule in the defined policy are met.

[!note] If you have merge request pipelines enabled for your project, you must set the AST_ENABLE_MR_PIPELINES CI/CD variable to "true" in your policy for each enforced scan. For more information on using security scanning tools with merge request pipelines, refer to the security scanning documentation.

Scanner behavior

Some scanners behave differently in a scan action than they do in a regular CI/CD pipeline scan:

• Static application security testing (SAST): Runs only if the repository contains files supported by SAST.
• Secret detection:
  • Only rules in the default ruleset are supported by default.
  • To customize a ruleset configuration, either:
    • Modify the default ruleset. Use a scan execution policy to specify the SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD variable. By default, this points to a remote configuration file that only overrides or disables rules from the default ruleset. Using only this variable does not support extending or replacing the default set of rules.
    • Extend or replace the default ruleset. Use the scan execution policy to specify the SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD variable and a remote configuration file that uses a Git passthrough to extend or replace the default ruleset. For a detailed guide, see How to set up a centrally managed pipeline secret detection configuration.
  • For scheduled scan execution policies, secret detection by default runs first in historic mode (SECRET_DETECTION_HISTORIC_SCAN = true). All subsequent scheduled scans run in default mode with SECRET_DETECTION_LOG_OPTIONS set to the commit range between last run and current SHA. You can override this behavior by specifying CI/CD variables in the scan execution policy. For more information, see Full history pipeline secret detection.
  • For triggered scan execution policies, secret detection works just like regular scan configured manually in the .gitlab-ci.yml.
• Container scanning: A scan that is configured for the pipeline rule type ignores the agent defined in the agents object. The agents object is only considered for schedule rule types. An agent with a name provided in the agents object must be created and configured for the project.

DAST profiles

The following requirements apply when enforcing dynamic application security testing (DAST):

• For every project in the policy's scope the specified site profile and scanner profile must exist. If these are not available, the policy is not applied and a job with an error message is created instead.
• When a DAST site profile or scanner profile is named in an enabled scan execution policy, the profile cannot be modified or deleted. To edit or delete the profile, you must first set the policy to Disabled in the policy editor or set enabled: false in the YAML mode.
• When configuring policies with a scheduled DAST scan, the author of the commit in the security policy project's repository must have access to the scanner and site profiles. Otherwise, the scan is not scheduled successfully.

Scan settings

The following settings are supported by the scan_settings parameter:

CI/CD variables

[!warning] Don't store sensitive information or credentials in variables because they are stored as part of the plaintext policy configuration in a Git repository.

Variables defined in a scan execution policy follow the standard CI/CD variable precedence.

Preconfigured values are used for the following CI/CD variables in any project on which a scan execution policy is enforced. Only policies can override these values. Group or project CI/CD variables cannot override these variables:

DS_EXCLUDED_PATHS: spec, test, tests, tmp
SAST_EXCLUDED_PATHS: spec, test, tests, tmp
SECRET_DETECTION_EXCLUDED_PATHS: ''
SECRET_DETECTION_HISTORIC_SCAN: false
SAST_EXCLUDED_ANALYZERS: ''
DEFAULT_SAST_EXCLUDED_PATHS: spec, test, tests, tmp
DS_EXCLUDED_ANALYZERS: ''
SECURE_ENABLE_LOCAL_CONFIGURATION: true

In GitLab 16.9 and earlier:

• If the CI/CD variables suffixed _EXCLUDED_PATHS were declared in a policy, their values could be overridden by a group or project's CI/CD variables.
• If the CI/CD variables suffixed _EXCLUDED_ANALYZERS were declared in a policy, their values were ignored, regardless of where they were defined: policy, group, or project.

Policy scope schema

To customize policy enforcement, you can define a policy's scope to either include, or exclude, specified projects, groups, or compliance framework labels. For more details, see Scope.

[!note] Setting a policy_scope field to an empty collection (for example, including: []) is treated the same as omitting the field, so the policy applies to all projects for that scope dimension. To disable a policy entirely, use enabled: false. For more details, see Empty collections in policy_scope.

Policy update propagation

When you update a policy, the changes propagate differently depending on how you update the policy:

• With a merge request on the security policy project: Changes take effect immediately after the merge request is merged.
• Direct commits to .gitlab/security-policies/policy.yml: Changes can take up to 10 minutes to take effect.

Triggering behavior

Updates to pipeline-based policies (type: pipeline) do not trigger immediate pipelines or affect pipelines already in progress. The policy changes apply to future pipeline runs.

You cannot manually trigger the rules in a scheduled policy outside their scheduled cadence.

Example security policy project

You can use this example in a .gitlab/security-policies/policy.yml file stored in a security policy project:

---
scan_execution_policy:
- name: Enforce DAST in every release pipeline
  description: This policy enforces pipeline configuration to have a job with DAST scan for release branches
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: dast
    scanner_profile: Scanner Profile A
    site_profile: Site Profile B
- name: Enforce DAST and secret detection scans every 10 minutes
  description: This policy enforces DAST and secret detection scans to run every 10 minutes
  enabled: true
  rules:
  - type: schedule
    branches:
    - main
    cadence: "*/10 * * * *"
  actions:
  - scan: dast
    scanner_profile: Scanner Profile C
    site_profile: Site Profile D
  - scan: secret_detection
    scan_settings:
      ignore_default_before_after_script: true
- name: Enforce secret detection and container scanning in every default branch pipeline
  description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
    variables:
      SAST_EXCLUDED_ANALYZERS: brakeman
  - scan: container_scanning

In this example:

• For every pipeline executed on branches that match the release/* wildcard (for example, branch release/v1.2.1)
  • DAST scans run with Scanner Profile A and Site Profile B.
• DAST and secret detection scans run every 10 minutes. The DAST scan runs with Scanner Profile C and Site Profile D.
• Secret detection, container scanning, and SAST scans run for every pipeline executed on the main branch. The SAST scan runs with the SAST_EXCLUDED_ANALYZER variable set to "brakeman".

Example for scan execution policy editor

You can use this example in the YAML mode of the scan execution policy editor. It corresponds to a single object from the previous example.

name: Enforce secret detection and container scanning in every default branch pipeline
description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
enabled: true
rules:
  - type: pipeline
    branches:
      - main
actions:
  - scan: secret_detection
  - scan: container_scanning

Avoiding duplicate scans

Scan execution policies can cause the same type of scanner to run more than once if you include scan jobs in your project's .gitlab-ci.yml file.

The duplicate scans run intentionally because scanners can run more than once with different variables and settings. For example, you might run a SAST scan with different variables than the ones enforced through your policies. In this scenario, two SAST jobs run in the pipeline:

• One with custom variables.
• One with the policy-enforced variables.

To prevent duplicate scans, you can either remove one of the scans from the project's .gitlab-ci.yml file or skip local jobs with variables. Skipping jobs does not prevent any security jobs defined by scan execution policies from running.

To skip scan jobs with variables, you can use:

• SAST_DISABLED: "true" to skip SAST jobs.
• DAST_DISABLED: "true" to skip DAST jobs.
• CONTAINER_SCANNING_DISABLED: "true" to skip container scanning jobs.
• SECRET_DETECTION_DISABLED: "true" to skip secret detection jobs.
• DEPENDENCY_SCANNING_DISABLED: "true" to skip dependency scanning jobs.

For an overview of all variables that can skip jobs, see CI/CD variables documentation

Troubleshooting

When working with scan execution policies, you might encounter the following issues.

Scan execution policy pipelines are not created

If a scan execution policy does not create a pipeline defined in type: pipeline as expected, you might have workflow:rules in the project's .gitlab-ci.yml file that prevent the policy from creating the pipeline.

Scan execution policies with type: pipeline rules rely on the merged CI/CD configuration to create pipelines. If the project's workflow:rules filter out the pipeline entirely, the scan execution policy cannot create pipelines.

For example, the following workflow:rules configuration prevents all pipelines from being created:

# .gitlab-ci.yml
workflow:
  rules:
  - if: $CI_PIPELINE_SOURCE == "push"
    when: never

Resolution:

To resolve this issue, you can use any of these options:

• Modify the workflow:rules in your project's .gitlab-ci.yml file to allow scan execution policies to create pipelines. You can use the $CI_PIPELINE_SOURCE variable to identify pipelines that are triggered by policies:

  yamlCopy

  workflow:
    rules:
    - if: $CI_PIPELINE_SOURCE == "security_orchestration_policy"
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never
  

• Use type: schedule rules instead of type: pipeline rules. Scheduled scan execution policies are not affected by workflow:rules and create pipelines according to their defined schedule.

• Use pipeline execution policies for more control over when and how security scans are executed in your CI/CD pipelines.