GitLab compliance pipelines ensure security- and compliance-related jobs in applicable projects are run in accordance with compliance frameworks. Similarly, scan execution policies assure GitLab security scans are run in pipelines in a compliant manner.

What we’ve learned from users is that they’d like to capture benefits offered by each feature through a single, simpler solution. Users would like to combine the flexibility of compliance pipelines with the simplicity and versatility of security policies.

To meet this request, we developed a new feature, pipeline execution policies, to help users enforce customized CI/CD jobs for all applicable projects. Pipeline execution policies perform a similar function to compliance pipelines, but with increased focus on compliance enforcement, flexibility, and a foundation to build and solve for more use cases in the future.

To reduce confusion, compliance pipelines have been deprecated in 17.3 now that pipeline execution policies are available and, as part of the deprecation, we are providing a step-by-step workflow for migrating from compliance pipelines to pipeline execution policy type in 17.5.

You can follow along with the work we’re doing with the deprecation through this epic.

Why are we deprecating compliance pipelines?

To understand the reason behind this change, we first need to understand the difference between the compliance management and policy management features in GitLab. With compliance management, we are focused on helping you understand your compliance posture, providing tools to report to auditors, and surfacing compliance risks in a way that helps you take action.

We are also focused on increasing compliance visibility of framework requirements, violations, and audit events throughout the entire DevSecOps lifecycle. Our compliance management offering also establishes a direct association between controls and automations configured through policies back into compliance requirements established through compliance frameworks.

Policy management works hand in hand with compliance programs, as well as supporting scalable security initiatives. Policies give organizations a central location to globally enforce security controls, compliance controls, and automate security and compliance workflows. Security policies will continue to address core use cases across the lifecycle, such as defining enforcement around CI/CD component usage, blocking risks related to dependency and package management, and automating vulnerability management workflows to address security and compliance controls.

Therefore, to ensure we provide the greatest value for our security and compliance users, we are deprecating compliance pipelines and providing a migration path for users to security policies. Not only does this make it clear and simple to the user how and when to enforce jobs as part of a project pipeline, but it also makes the distinction between compliance management and policy management in GitLab clearer. Compliance management is focused on compliance visibility, and policy management is focused on compliance and security enforcement across your entire GitLab instance.

What is the timeline for the deprecation and removal of compliance pipelines?

The iteration plan below can be found in the issue that details the work we are doing to deprecate and remove compliance pipelines:

Deprecation announcement

• Compliance pipeline deprecation and removal was announced in 17.3

Compliance pipelines maintenance mode

• Adding banners and migration workflow, and docs
• Released in 17.5

Deter new compliance pipelines

• Adding warning banners for new pipelines
• Encourage users to try the pipeline execution policy instead
• Scheduled to start work on this 17.5
• Scheduled to be released 17.6

Compliance pipelines removal (Remove compliance pipelines)

• Provide tools to trial the removal and validate any errors
• Scheduled to start work on this 17.8
• Scheduled to be released 18.0

As you can see, we will start with the deprecation of compliance pipelines and the introduction of pipeline execution policy in the 17.3 release.

Leading up to the removal of compliance pipelines in the 18.0 release, we are including new ways to inform and warn users about the upcoming removal. We are providing warning banners on new pipelines, as well as a workflow that can be used to migrate compliance pipelines to pipeline execution policy.

We ‘ll remove compliance pipelines in the 18.0 release, but provide a reverse feature flag in the milestones leading up that will help users test the removal and understand any impact prior to the removal date.

How to migrate your compliance pipelines to pipeline execution policy?

There are two ways users can access the workflow for migrating compliance pipelines to pipeline execution policy.

1. When creating a new compliance framework, there will now be a warning banner that allows users to start using pipeline execution policy type instead of compliance frameworks:

2. When editing an existing compliance framework, there will now be a warning banner that enables users to migrate their compliance pipelines to pipeline execution policy type – if they have a compliance pipeline configured.

Selecting either "Create policy" or "Migrate pipeline to a policy" in either workflow will bring users to the "New policy" creation page in the "Security Policies" section. This will allow users to create a new security policy instead of a compliance pipeline. Or, if you migrate an existing compliance pipeline, the new policy will be populated with the compliance pipeline YAML as the remote source for the policy. Also, the policy scope will be populated with the framework from which you are migrating.

The policy will target all projects with that label for enforcement and apply enforcement of jobs defined in your remote file, now the pipeline execution YAML. By default, the new policy will be configured with the “override” mode, which will override downstream projects' .gitlab-ci.yml with the configuration you have defined (similar to compliance pipelines).

Alternatively, you may use the “Inject” mode, which introduces a new set of reserved stages to run security and compliance jobs in isolation in a tamper-proof manner, without disrupting the project pipeline, and without coordinating with project teams to define stage names in their pipeline config.

With this approach, be sure to remove the include:project, which is no longer needed for this mode. And, depending on your version, ensure job names are unique (required in GitLab 17.2 and 17.3). In GitLab 17.4, we introduced additional enhancements for managing conflicts for additional flexibility.

Start your migration today

We want to ensure that all GitLab users who are using compliance pipelines are fully aware of the deprecation of compliance pipelines in 17.3 and its eventual removal by the 18.0 release as a breaking change.

We are asking users to start migrating their compliance pipelines to the pipeline execution policy type as soon as possible, before the removal of compliance pipelines in GitLab 18.0.

If there are any questions, please contact your customer service representative or GitLab support for any help.

Follow along with the compliance pipeline deprecation progress in this epic.

Share feedback in this issue regarding any gaps are blockers for adopting pipeline execution policies.