A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/ below:

Pipeline execution policies | GitLab Docs

History

Use pipeline execution policies to manage and enforce CI/CD jobs for multiple projects with a single configuration.

Schema

History

The YAML file with pipeline execution policies consists of an array of objects matching pipeline execution policy schema nested under the pipeline_execution_policy key. You can configure a maximum of five policies under the pipeline_execution_policy key per security policy project. Any other policies configured after the first five are not applied.

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

Field Type Required Description pipeline_execution_policy array of pipeline execution policy true List of pipeline execution policies (maximum five) pipeline_execution_policy schema Field Type Required Description name string true Name of the policy. Maximum of 255 characters. description (optional) string true Description of the policy. enabled boolean true Flag to enable (true) or disable (false) the policy. content object of content true Reference to the CI/CD configuration to inject into project pipelines. pipeline_config_strategy string false Can be inject_policy, inject_ci (deprecated), or override_project_ci. See pipeline strategies for more information. policy_scope object of policy_scope false Scopes the policy based on projects, groups, or compliance framework labels you specify. suffix string false Can either be on_conflict (default), or never. Defines the behavior for handling job naming conflicts. on_conflict applies a unique suffix to the job names for jobs that would break the uniqueness. never causes the pipeline to fail if the job names across the project and all applicable policies are not unique. skip_ci object of skip_ci false Defines whether users can apply the skip-ci directive. By default, the use of skip-ci is ignored and as a result, pipelines with pipeline execution policies cannot be skipped. variables_override object of variables_override false Controls whether users can override the behavior of policy variables. By default, the policy variables are enforced with the highest precedence and users cannot override them.

Note the following:

.pipeline-policy-pre stage

Jobs in the .pipeline-policy-pre stage always execute. This stage is designed for security and compliance use cases. Jobs in the pipeline do not begin until the .pipeline-policy-pre stage completes.

If you don’t require this behavior for your workflow, you can use the .pre stage or a custom stage instead.

Ensure that .pipeline-policy-pre succeeds

This feature is experimental and might change in future releases. Test it thoroughly in non-production environments only, as it might be unstable in production.

To ensure that .pipeline-policy-pre completes and succeeds, enable the ensure_pipeline_policy_pre_succeeds experiment in the security policy configuration. The .gitlab/security-policies/policy.yml YAML configuration file is stored in your security policy project:

experiments:
  ensure_pipeline_policy_pre_succeeds:
    enabled: true

If the .pipeline-policy-pre stage fails or all jobs in the stage are skipped, all jobs in later stages are skipped, including:

When multiple pipeline execution policies apply, the experiment takes effect if enabled in any of them, ensuring that .pipeline-policy-pre must succeed.

Job naming best practice

History

There is no visible indicator that a job was generated by a security policy. To make it easier to identify jobs that were created by policies and avoid job name collisions, add a unique prefix or suffix to the job name.

Examples:

Pipeline execution policies handle naming conflicts depending on the suffix attribute. If there are multiple jobs with the same name:

The suffix is added based on the order in which the jobs are merged onto the main pipeline.

The order is as follows:

  1. Project pipeline jobs
  2. Project policy jobs (if applicable)
  3. Group policy jobs (if applicable, ordered by hierarchy, the most top-level group is applied as last)

The applied suffix has the following format:

:policy-<security-policy-project-id>-<policy-index>.

Example of the resulting job: sast:policy-123456-0.

If multiple policies in on security policy project define the same job name, the numerical suffix corresponds to the index of the conflicting policy.

Example of the resulting jobs:

Job stage best practice

Jobs defined in a pipeline execution policy can use any stage defined in the project’s CI/CD configuration, also the reserved stages .pipeline-policy-pre and .pipeline-policy-post.

If your policy contains jobs only in the .pre and .post stages, the policy’s pipeline is evaluated as empty. It is not merged with the project’s pipeline.

To use the .pre and .post stages in a pipeline execution policy, you must include at least one other job that runs in a different stage. For example: .pipeline-policy-pre.

When you use the inject_policy pipeline strategy, if a target project does not contain its own .gitlab-ci.yml file, all policy stages are injected into the pipeline.

When you use the (deprecated) inject_ci pipeline strategy, if a target project does not contain its own .gitlab-ci.yml file, then the only stages available are the default pipeline stages and the reserved stages.

When you enforce pipeline execution policies over projects with CI/CD configurations that you do not have permissions to modify, you should define jobs in the .pipeline-policy-pre and .pipeline-policy-post stages. These stages are always available, regardless of any project’s CI/CD configuration.

When you use the override_project_ci pipeline strategy with multiple pipeline execution policies and with custom stages, the stages must be defined in the same relative order to be compatible with each other:

Valid configuration example:

  - override-policy-1 stages: [build, test, policy-test, deploy]
  - override-policy-2 stages: [test, deploy]

Invalid configuration example:

  - override-policy-1 stages: [build, test, policy-test, deploy]
  - override-policy-2 stages: [deploy, test]

The pipeline fails if one or more override_project_ci policies has an invalid stages configuration.

content type Field Type Required Description project string true The full GitLab project path to a project on the same GitLab instance. file string true A full file path relative to the root directory (/). The YAML files must have the .yml or .yaml extension. ref string false The ref to retrieve the file from. Defaults to the HEAD of the project when not specified.

Use the content type in a policy to reference a CI/CD configuration stored in another repository. This allows you to reuse the same CI/CD configuration across multiple policies, reducing the overhead of maintaining these configurations. For example, if you have a custom secret detection CI/CD configuration you want to enforce in policy A and policy B, you can create a single YAML configuration file and reference the configuration in both policies.

Prerequisites:

skip_ci type

History

Pipeline 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.

Field Type Possible values Description allowed boolean true, false Flag to allow (true) or prevent (false) the use of the skip-ci directive for pipelines with enforced pipeline execution policies. allowlist object users Specify users who are always allowed to use skip-ci directive, regardless of the allowed flag. Use users: followed by an array of objects with id keys representing user IDs. variables_override type

History

Field Type Possible values Description allowed boolean true, false When true, other configurations can override policy variables. When false, other configurations cannot override policy variables. exceptions array array of string Variables that are exceptions to the global rule. When allowed: false, the exceptions are an allowlist. When allowed: true, the exceptions are a denylist.

This option controls how user-defined variables are handled in pipelines with policies enforced. This feature allows you to:

User-defined variables can affect the behavior of any policy jobs in the pipeline and can come from various sources:

When the variables_override option is not specified, the “highest precedence” behavior is maintained. For more information about this behavior, see precedence of variables in pipeline execution policies.

When the pipeline execution policy controls variable precedence, the job logs include the configured variables_override options and the policy name. To view these logs, gitlab-runner must be updated to version 18.1 or later.

Example variables_override configuration

Add the variables_override option to your pipeline execution policy configuration:

pipeline_execution_policy:
  - name: Security Scans
    description: 'Enforce security scanning'
    enabled: true
    pipeline_config_strategy: inject_policy
    content:
      include:
        - project: gitlab-org/security-policies
          file: security-scans.yml
    variables_override:
      allowed: false
      exceptions:
        - CS_IMAGE
        - SAST_EXCLUDED_ANALYZERS
Enforcing security scans while allowing container customization (allowlist approach)

To enforce security scans but allow project teams to specify their own container image:

variables_override:
  allowed: false
  exceptions:
    - CS_IMAGE

This configuration blocks all user-defined variables except CS_IMAGE, ensuring that security scans cannot be disabled, while allowing teams to customize the container image.

Prevent specific security variable overrides (denylist approach)

To allow most variables, but prevent disabling security scans:

variables_override:
  allowed: true
  exceptions:
    - SECRET_DETECTION_DISABLED
    - SAST_DISABLED
    - DEPENDENCY_SCANNING_DISABLED
    - DAST_DISABLED
    - CONTAINER_SCANNING_DISABLED

This configuration allows all user-defined variables except those that could disable security scans.

While this configuration can provide flexibility, it is discouraged due to the security implications. Any variable that is not explicitly listed in the exceptions can be injected by the users. As a result, the policy configuration is not as well protected as when using the allowlist approach.

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.

Manage access to the CI/CD configuration

When you enforce pipeline execution policies on a project, users that trigger pipelines must have at least read-only access to the project that contains the policy CI/CD configuration. You can grant access to the project manually or automatically.

Grant access manually

To allow users or groups to run pipelines with enforced pipeline execution policies, you can invite them to the project that contains the policy CI/CD configuration.

Grant access automatically

You can automatically grant access to the policy CI/CD configuration for all users who run pipelines in projects with enforced pipeline execution policies.

Prerequisites:

If you don’t yet have a security policy project and you want to create the first pipeline execution policy, create an empty project and link it as a security policy project. To link the project:

  1. In the group or project where you want to enforce the policy, select Secure > Policies > Edit policy project.
  2. Select the security policy project.

The project becomes a security policy project, and the setting becomes available.

To create downstream pipelines using $CI_JOB_TOKEN, you need to make sure that projects and groups are authorized to request the security policy project. In the security policy project, go to Settings > CI/CD > Job token permissions and add the authorized groups and projects to the allowlist. If you don’t see the CI/CD settings, go to Settings > General > Visibility, project features, permissions and enable CI/CD.

Configuration

  1. In the policy project, select Settings > General > Visibility, project features, permissions.

  2. Enable the setting Pipeline execution policies: Grant access to the CI/CD configurations for projects linked to this security policy project as the source for security policies.

  3. In the policy project, create a file for the policy CI/CD configuration.

    # policy-ci.yml

policy-job:
  script: ...

  4. In the group or project where you want to enforce the policy, create a pipeline execution policy and specify the CI/CD configuration file for the security policy project.

    pipeline_execution_policy:
- name: My pipeline execution policy
  description: Enforces CI/CD jobs
  enabled: true
  pipeline_config_strategy: inject_policy
  content:
    include:
    - project: my-group/my-security-policy-project
      file: policy-ci.yml
Pipeline configuration strategies

Pipeline configuration strategy defines the method for merging the policy configuration with the project pipeline. Pipeline execution policies execute the jobs defined in the .gitlab-ci.yml file in isolated pipelines, which are merged into the pipelines of the target projects.

inject_policy type

History

This strategy adds custom CI/CD configurations into the existing project pipeline without completely replacing the project’s original CI/CD configuration. It is suitable when you want to enhance or extend the current pipeline with additional steps, such as adding new security scans, compliance checks, or custom scripts.

Unlike the deprecated inject_ci strategy, inject_policy allows you to inject custom policy stages into your pipeline, giving you more granular control over where policy rules are applied in your CI/CD workflow.

If you have multiple policies enabled, this strategy injects all of jobs from each policy.

When you use this strategy, a project CI/CD configuration cannot override any behavior defined in the policy pipelines because each pipeline has an isolated YAML configuration.

For projects without a .gitlab-ci.yml file, this strategy creates .gitlab-ci.yml file implicitly. The executed pipeline contains only the jobs defined in the pipeline execution policy.

When a pipeline execution policy uses workflow rules that prevent policy jobs from running, the only jobs that run are the project’s CI/CD jobs. If the project uses workflow rules that prevent project CI/CD jobs from running, the only jobs that run are the pipeline execution policy jobs.

Stages injection

The stages for the policy pipeline follow the usual CI/CD configuration. You define the order in which a custom policy stage is injected into the project pipeline by providing the stages before and after the custom stages.

The project and policy pipeline stages are represented as a Directed Acyclic Graph (DAG), where nodes are stages and edges represent dependencies. When you combine pipelines, the individual DAGs are merged into a single, larger DAG. Afterward, a topological sorting is performed, which determines the order in which stages from all pipelines should execute. This sorting ensures that all dependencies are respected in the final order. If there are conflicting dependencies, the pipeline fails to run. To fix the dependencies, ensure that stages used across the project and policies are aligned.

If a stage isn’t explicitly defined in the policy pipeline configuration, the pipeline uses the default stages stages: [build, test, deploy]. If these stages are included, but listed in a different order, the pipeline fails with a Cyclic dependencies detected when enforcing policies error.

The following examples demonstrate this behavior. All examples assume the following project CI/CD configuration:

# .gitlab-ci.yml
stages: [build, test, deploy]

project-build-job:
  stage: build
  script: ...

project-test-job:
  stage: test
  script: ...

project-deploy-job:
  stage: deploy
  script: ...
Example 1 
# policy-ci.yml
stages: [test, policy-stage, deploy]

policy-job:
  stage: policy-stage
  script: ...

In this example, the policy-stage stage:

Result: The pipeline contains the following stages: [build, test, policy-stage, deploy].

Special cases:

Example 2 
# policy-ci.yml
stages: [policy-stage, deploy]

policy-job:
  stage: policy-stage
  script: ...

In this example, the policy-stage stage:

Result: The pipeline contains the following stages: [build, test, policy-stage, deploy].

Special cases:

Example 3 
# policy-ci.yml
stages: [test, policy-stage]

policy-job:
  stage: policy-stage
  script: ...

In this example, the policy-stage stage:

Result: The pipeline contains the following stages: [build, test, deploy, policy-stage].

Special cases:

Example 4 
# policy-ci.yml
stages: [policy-stage]

policy-job:
  stage: policy-stage
  script: ...

In this example, the policy-stage stage has no constraints.

Result: The pipeline contains the following stages: [build, test, deploy, policy-stage].

Example 5 
# policy-ci.yml
stages: [check, lint, test, policy-stage, deploy, verify, publish]

policy-job:
  stage: policy-stage
  script: ...

In this example, the policy-stage stage:

Result: The pipeline contains the following stages: [build, test, policy-stage, deploy].

Special cases:

inject_ci (deprecated)

This feature was deprecated in GitLab 17.9. Use inject_policy instead as it supports the enforcement of custom policy stages.

This strategy adds custom CI/CD configurations into the existing project pipeline without completely replacing the project’s original CI/CD configuration. It is suitable when you want to enhance or extend the current pipeline with additional steps, such as adding new security scans, compliance checks, or custom scripts.

Having multiple policies enabled injects all jobs additively.

When you use this strategy, a project CI/CD configuration cannot override any behavior defined in the policy pipelines because each pipeline has an isolated YAML configuration.

For projects without a .gitlab-ci.yml file, this strategy creates a .gitlab-ci.yml file implicitly. This allows a pipeline containing only the jobs defined in the pipeline execution policy to execute.

When a pipeline execution policy uses workflow rules that prevent policy jobs from running, the only jobs that run are the project’s CI/CD jobs. If the project uses workflow rules that prevent project CI/CD jobs from running, the only jobs that run are the pipeline execution policy jobs.

override_project_ci

History

This strategy replaces the project’s existing CI/CD configuration with a new one defined by the pipeline execution policy. This strategy is ideal when the entire pipeline needs to be standardized or replaced, like when you want to enforce organization-wide CI/CD standards or compliance requirements in a highly regulated industry. To override the pipeline configuration, define the CI/CD jobs and do not use include:project.

The strategy takes precedence over other policies that use the inject_ci or inject_policy strategy. If a policy with override_project_ci applies, the project CI/CD configuration is ignored. However, other security policy configurations are not overridden.

When you use override_project_ci in a pipeline execution policy together with a scan execution policy, the CI/CD configurations are merged and both policies are applied to the resulting pipeline.

Alternatively, you can merge the project’s CI/CD configuration with the project’s .gitlab-ci.yml instead of overriding it. To merge the configuration, use include:project. This strategy allows users to include the project CI/CD configuration in the pipeline execution policy configuration, enabling the users to customize the policy jobs. For example, they can combine the policy and project CI/CD configuration into one YAML file to override the before_script configuration or define required variables, such as CS_IMAGE, to define the required path to the container to scan. Here’s a short demo of this behavior. The following diagram illustrates how variables defined at the project and policy levels are selected in the resulting pipeline:

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TB

classDef yaml text-align:left

ActualPolicyYAML["<pre>
variables:
  MY_VAR: 'policy'
policy-job:
  stage: test
</pre>"]

class ActualPolicyYAML yaml

ActualProjectYAML["<pre>
variables:
  MY_VAR: 'project'
project-job:
  stage: test
</pre>"]

class ActualProjectYAML yaml

PolicyVariablesYAML["<pre>
variables:
  MY_VAR: 'policy'
</pre>"]

class PolicyVariablesYAML yaml

ProjectVariablesYAML["<pre>
variables:
  MY_VAR: 'project'
</pre>"]

class ProjectVariablesYAML yaml

ResultingPolicyVariablesYAML["<pre>
variables:
  MY_VAR: 'policy'
</pre>"]

class ResultingPolicyVariablesYAML yaml

ResultingProjectVariablesYAML["<pre>
variables:
  MY_VAR: 'project'
</pre>"]

class ResultingProjectVariablesYAML yaml

PolicyCiYAML(Policy CI YAML) --> ActualPolicyYAML
ProjectCiYAML(<code>.gitlab-ci.yml</code>) --> ActualProjectYAML

subgraph "Policy Pipeline"
  subgraph "Test stage"
    subgraph "<code>policy-job</code>"
      PolicyVariablesYAML
    end
  end
end

subgraph "Project Pipeline"
  subgraph "Test stage"
    subgraph "<code>project-job</code>"
      ProjectVariablesYAML
    end
  end
end

ActualPolicyYAML -- "Used as source" --> PolicyVariablesYAML
ActualProjectYAML -- "Used as source" --> ProjectVariablesYAML

subgraph "Resulting Pipeline"
  subgraph "Test stage"
    subgraph "<code>policy-job</code> "
      ResultingPolicyVariablesYAML
    end

    subgraph "<code>project-job</code> "
      ResultingProjectVariablesYAML
    end
  end
end

PolicyVariablesYAML -- "Inject <code>policy-job</code> if Test Stage exists" --> ResultingPolicyVariablesYAML
ProjectVariablesYAML -- "Basis of the resulting pipeline" --> ResultingProjectVariablesYAML

The workflow rules in the pipeline execution policy override the project’s original CI/CD configuration. By defining workflow rules in the policy, you can set rules that are enforced across all linked projects, like preventing the use of branch pipelines.

Include a project’s CI/CD configuration in the pipeline execution policy configuration

When you use the override_project_ci strategy, the project configuration can be included into the pipeline execution policy configuration:

include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: $CI_CONFIG_PATH
    rules:
      - exists:
          paths:
            - '$CI_CONFIG_PATH'
          project: '$CI_PROJECT_PATH'
          ref: '$CI_COMMIT_SHA'

compliance_job:
 ...
CI/CD variables

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

Pipeline execution jobs are executed in isolation. Variables defined in another policy or in the project’s .gitlab-ci.yml file are not available in the pipeline execution policy and cannot be overwritten from the outside, unless permitted by the variables_override type type.

Variables can be shared with pipeline execution policies using group or project settings, which follow the standard CI/CD variable precedence rules. However, the precedence rules are more complex when using a pipeline execution policy as they can vary depending on the pipeline execution policy strategy:

For more details on variable in pipeline execution policies, see precedence of variable in pipeline execution policies.

You can define project or group variables in the UI.

Precedence of variables in pipeline execution policies

When you use pipeline execution policies, especially with the override_project_ci strategy, the precedence of variable values defined in multiple places can differ from standard GitLab CI/CD pipelines. These are some important points to understand:

Example

If a variable in a project’s CI/CD configuration and a job variable defined in an included .gitlab-ci.yml file have the same name, the job variable takes precedence when using override_project_ci.

In the project’s CI/CD settings, a MY_VAR variable is defined:

In .gitlab-ci.yml of the included project, the same variable is defined:

project-job:
  variables:
    MY_VAR: "Project job variable value"
  script:
    - echo $MY_VAR  # This will output "Project job variable value"

In this case, the job variable value Project job variable value takes precedence.

Behavior with [skip ci]

By default, to prevent a regular pipeline from triggering, users can push a commit to a protected branch with [skip ci] in the commit message. However, jobs defined with a pipeline execution policy are always triggered, as the policy ignores the [skip ci] directive. This prevents developers from skipping the execution of jobs defined in the policy, which ensures that critical security and compliance checks are always performed.

For more flexible control over [skip ci] behavior, see the skip_ci type section.

Examples

These examples demonstrate what you can achieve with pipeline execution policies.

Pipeline execution policy

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

---
pipeline_execution_policy:
- name: My pipeline execution policy
  description: Enforces CI/CD jobs
  enabled: true
  pipeline_config_strategy: override_project_ci
  content:
    include:
    - project: my-group/pipeline-execution-ci-project
      file: policy-ci.yml
      ref: main # optional
  policy_scope:
    projects:
      including:
      - id: 361
Customize enforced jobs based on project variables

You can customize enforced jobs, based on the presence of a project variable. In this example, the value of CS_IMAGE is defined in the policy as alpine:latest. However, if the project also defines the value of PROJECT_CS_IMAGE, that value is used instead. The CI/CD variable must be a predefined project variable, not defined in the project’s .gitlab-ci.yml file.

variables:
  CS_ANALYZER_IMAGE: "$CI_TEMPLATE_REGISTRY_HOST/security-products/container-scanning:8"
  CS_IMAGE: alpine:latest

policy::container-security:
  stage: .pipeline-policy-pre
  rules:
    - if: $PROJECT_CS_IMAGE
      variables:
        CS_IMAGE: $PROJECT_CS_IMAGE
    - when: always
  script:
    - echo "CS_ANALYZER_IMAGE:$CS_ANALYZER_IMAGE"
    - echo "CS_IMAGE:$CS_IMAGE"
Customize enforced jobs using .gitlab-ci.yml and artifacts

Because policy pipelines run in isolation, pipeline execution policies cannot read variables from .gitlab-ci.yml directly. If you want to use the variables in .gitlab-ci.yml instead of defining them in the project’s CI/CD configuration, you can use artifacts to pass variables from the .gitlab-ci.yml configuration to the pipeline execution policy’s pipeline.

# .gitlab-ci.yml

build-job:
  stage: build
  script:
    - echo "BUILD_VARIABLE=value_from_build_job" >> build.env
  artifacts:
    reports:
      dotenv: build.env
stages:
- build
- test

test-job:
  stage: test
  script:
    - echo "$BUILD_VARIABLE" # Prints "value_from_build_job"
Customize security scanner’s behavior with before_script in project configurations

To customize the behavior of a security job enforced by a policy in the project’s .gitlab-ci.yml, you can override before_script. To do so, use the override_project_ci strategy in the policy and include the project’s CI/CD configuration. Example pipeline execution policy configuration:

# policy.yml
type: pipeline_execution_policy
name: Secret detection
description: >-
  This policy enforces secret detection and allows projects to override the
  behavior of the scanner.
enabled: true
pipeline_config_strategy: override_project_ci
content:
  include:
    - project: gitlab-org/pipeline-execution-policies/compliance-project
      file: secret-detection.yml
# secret-detection.yml
include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: $CI_CONFIG_PATH
  - template: Jobs/Secret-Detection.gitlab-ci.yml

In the project’s .gitlab-ci.yml, you can define before_script for the scanner:

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  before_script:
    - echo "Before secret detection"

By using override_project_ci and including the project’s configuration, it allows for YAML configurations to be merged.

Configure resource-specific variable control

You can allow teams to set global variables that can override pipeline execution policy variables, while still permitting job-specific overrides. This allows teams to set appropriate defaults for security scans, but use appropriate resources for other jobs.

Include in your resource-optimized-scans.yml:

variables:
  # Default resource settings for all jobs
  KUBERNETES_MEMORY_REQUEST: 4Gi
  KUBERNETES_MEMORY_LIMIT: 4Gi
  # Default values that teams can override via project variables
  SAST_KUBERNETES_MEMORY_REQUEST: 4Gi

sast:
  variables:
    SAST_EXCLUDED_ANALYZERS: 'spotbugs'
    KUBERNETES_MEMORY_REQUEST: $SAST_KUBERNETES_MEMORY_REQUEST
    KUBERNETES_MEMORY_LIMIT: $SAST_KUBERNETES_MEMORY_REQUEST

Include in your policy.yml:

pipeline_execution_policy:
- name: Resource-Optimized Security Policy
  description: Enforces security scans with efficient resource management
  enabled: true
  pipeline_config_strategy: inject_ci
  content:
    include:
    - project: security/policy-templates
      file: resource-optimized-scans.yml
      ref: main

  variables_override:
    allowed: false
    exceptions:
      # Allow scan-specific resource overrides
      - SAST_KUBERNETES_MEMORY_REQUEST
      - SECRET_DETECTION_KUBERNETES_MEMORY_REQUEST
      - CS_KUBERNETES_MEMORY_REQUEST
      # Allow necessary scan customization
      - CS_IMAGE
      - SAST_EXCLUDED_PATHS

This approach allows teams to set scan-specific resource variables (like SAST_KUBERNETES_MEMORY_REQUEST) using variable overrides without affecting all jobs in their pipeline, which provides better resource management for large projects. This example also shows the use of other common scan customization options that you can extend to developers. Make sure you document the available variables so your development teams can leverage them.

Use group or project variables in a pipeline execution policy

You can use group or project variables in a pipeline execution policy.

With a project variable of PROJECT_VAR="I'm a project" the following pipeline execution policy job results in: I'm a project.

pipeline execution policy job:
    stage: .pipeline-policy-pre
    script:
    - echo "$PROJECT_VAR"
Enforce a variable’s value by using a pipeline execution policy

The value of a variable defined in a pipeline execution policy overrides the value of a group or policy variable with the same name. In this example, the project value of variable PROJECT_VAR is overwritten and the job results in: I'm a pipeline execution policy.

variables:
  PROJECT_VAR: "I'm a pipeline execution policy"

pipeline execution policy job:
    stage: .pipeline-policy-pre
    script:
    - echo "$PROJECT_VAR"
Example policy.yml with security policy scopes

In this example, the security policy’s policy_scope:

pipeline_execution_policy:
- name: Pipeline execution policy
  description: ''
  enabled: true
  pipeline_config_strategy: inject_policy
  content:
    include:
    - project: my-group/pipeline-execution-ci-project
      file: policy-ci.yml
  policy_scope:
    compliance_frameworks:
    - id: 9
    projects:
      excluding:
      - id: 456
Configure ci_skip in a pipeline execution policy

In the following example, the pipeline execution policy is enforced, and skipping CI is disallowed except for the user with ID 75.

pipeline_execution_policy:
  - name: My pipeline execution policy with ci.skip exceptions
    description: 'Enforces CI/CD jobs'
    enabled: true
    pipeline_config_strategy: inject_policy
    content:
      include:
        - project: group-a/project1
          file: README.md
    skip_ci:
      allowed: false
      allowlist:
        users:
          - id: 75
Configure the exists condition

Use the exists rule to configure the pipeline execution policy to include the CI/CD configuration file from the project when a certain file exists.

In the following example, the pipeline execution policy includes the CI/CD configuration from the project if a Dockerfile exists. You must set the exists rule to use '$CI_PROJECT_PATH' as the project, otherwise GitLab evaluates where the files exists in the project that holds the security policy CI/CD configuration.

include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: $CI_CONFIG_PATH
    rules:
      - exists:
          paths:
            - 'Dockerfile'
          project: '$CI_PROJECT_PATH'

To use this approach, the group or project must use the override_project_ci strategy.

Enforce a container scanning component using a pipeline execution policy

You can use security scan components to improve the handling and enforcement of versioning.

include:
  - component: gitlab.com/components/container-scanning/container-scanning@main
    inputs:
      cs_image: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

container_scanning: # override component with additional configuration
  variables:
    CS_REGISTRY_USER: $CI_REGISTRY_USER
    CS_REGISTRY_PASSWORD: $CI_REGISTRY_PASSWORD
    SECURE_LOG_LEVEL: debug # add for verbose debugging of the container scanner
  before_script:
  - echo $CS_IMAGE # optionally add a before_script for additional debugging

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4