Skip to content

馃摚 Feedback Issue: Pipeline Execution Policy Action & Linking Policies to Compliance Frameworks (Experimental Features)

Update: This experiment has ended

As of 17.2, we have now introduced a new policy type, the Pipeline Execution Policy. 馃摵 Watch this video to learn more! This new policy will allow you to create and enforce custom CI. The feedback captured from this experiment has informed the final GA solution and we are appreciative of all who participated and shared feedback 馃檱 !

We plan to remove the experiment in 17.3. If you want to enforce custom CI in your projects, please explore this newly released policy type.

Keep in mind that experiments are unstable and not intended for production use. They may break or be removed at any time. Learn more about experimental, beta, and generally available features.

馃帀 Introducing Pipeline Execution Policy Action & Scoping Policies to Compliance Frameworks (Experimental Feature)

In %16.8, we have enabled new experimental capabilities to our Security Policies, which include:

  1. Pipeline Execution Policy Action: Custom CI yaml configuration that can be enforced across your organization (and all development team projects) as a new action in the Scan Execution Policy type.
  2. Security Policy Scopes: Scoping and linking of security policies to compliance frameworks (or a target list of projectS), allowing you to granularly associate an individual policy to projects containing a compliance framework labels and a security policy project link.

These experimental features are now available for SaaS (once enabled for your groups) and will be available for Self-managed users in %16.8 (or feel free to create a test instance on SaaS to try now!).

With these improvements, you will be able to:

  • Create security and compliance controls that can be enforced across your organization granularly.
  • Create custom CI that can be defined atomically in scan execution policies to enforce security analyzers to execute across your projects. Pipeline Execution Policies (Scan Execution Policies with Custom CI) will support any other CI you might use in your .gitlab-ci.yml configuration today, such as security scanner templates, customized security scanner CI, external security scanners, external change management tools, custom reporting scripts, etc. The world is your oyster!
  • Define the scope of a security policy to filter enforcement based on compliance framework labels by linking policies to compliance frameworks (or a defined set of projects in a group). Instead of a batch of policies in a security policy project against a group, subgroup, or individually linking multiple projects, you may instead create links in groups or subgroups, and add scopes to policies for fine-grained enforcement.

To try the feature, you must use GitLab 16.8 and enable the experiment toggle for each group you want to enable it (Group > Settings > General > Permissions and group features).

Sharing Feedback - please read before posting!

Thanks so much for trying out our new experimental features!

  • Before leaving a comment, be sure to check out our current planned improvements and known issues.
  • For any internal GitLab team members, please leave all feedback in this issue, not slack.
  • We will read all of your feedback!
  • We may not be able to respond to all feedback, but appreciate all input! 馃檱
  • We will track any actions from feedback in the Actions section.
  • Remember these features are currently experimental. They are unstable and may break or change at any time!

Known Issues

  1. Security policy scoping appears in policy editors only for policies managed in a group or subgroup. If you have created policies managed at the project level, you will need to use YAML mode only. This is being addressed in #432513 (closed).
  2. Pipeline Execution Action is not enforced on projects without a CI configuration. - Fixed
  3. When using the remote file configuration to define pipeline execution, the project containing your remote file must be public. This is being addressed in !144727 (merged).

Track further plans and known issues in:

Actions

As we capture feedback, we can collect any new issues/enhancements key actions below:

  1. TBD
  2. TBD
  3. TBD
Edited by Grant Hickman