The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Protect |
| Maturity | Minimal |
| Content Last Reviewed | 2022-04-23 |
Thanks for visiting this category direction page on Security Orchestration in GitLab. This page belongs to the Container Security group of the Protect stage and is maintained by Sam White (swhite@gitlab.com).
This direction page is a work in progress, and everyone can contribute. We welcome feedback, bug reports, feature requests, and community contributions.
/label ~"devops::protect" ~"Category:Security Orchestration" ~"group::container security".
We believe everyone can contribute and so if you wish to contribute here is how to get started.
Security Orchestration is an overlay category that provides policy, alert, and security approval orchestration support for all the scanners and technologies used by GitLab's Secure and Protect stages. The goal is to provide a single, unified user experience that is consistent and intuitive.
The work done in the Security Orchestration category spans three key areas: Security Policy Management, Security Approvals, and Security Alert Management.
Security policies allow users to use a single, simple UI to define rules and actions that are then enforced. Security policies can be created to enforce cloud-native network firewall rules for applications in production. Users can also create policies to require vulnerability scans to be run, either on a specified schedule or as part of a pipeline job. Security policies themselves are fully audited and can be configured to go through a two-step approval process before any changes are made.
Security approvals allow users to select the conditions that must be met to trigger the security approval rule, including which branches, scanners, vulnerability count, and vulnerability severity levels must be present in the MR. If all conditions are met, then the merge request is blocked unless an eligible user approves the MR. This extra layer of oversight can serve as an enforcement mechanism as part of a strong security compliance program.
Security approvals are a type of Scan Result Security Policy and can be configured in the Security & Compliance > Policies page. This functionality replaces the functionality that was previously available in the Vulnerability-Check feature. Vulnerability-Check has been deprecated in GitLab 14.8 and is scheduled for removal in GitLab 15.0.
Although this category is new, our vision is broad. We plan to support both scan schedule and scan results policies for all of GitLab's scanners at the Workspace, Group, and Project levels. In addition, we intend to add full support for two-step approvals and proper audit trails of any changes made. In the long-run, we intend to provide visibility into the impact (blast radius) a policy will have before it is deployed, add support for complex orchestration policies, and auto-suggest policies based on your unique environment and codebase. Policy changes will need to be fully audited and optionally run through a two-step approval process.
Beyond policies, we also intend to add support for an Alert workflow that will allow users to be notified of events that require manual, human review to determine the next steps to take. This workflow will eventually support auto-suggested responses and recommended changes to policies to reduce false positives and automate responses whenever possible.
The matrixes below describe the scope of the work that is planned in the long-run for the Security Orchestration category as well as our progress toward the end goal. Eventually we would like to have support for most, if not all of the boxes in the tables below.
A full list of our near-term priorities is kept up-to-date on our open priorities issue. A short summary of the priorities for each feature within the Security Orchestration category is listed below.
Security Policies
Security Policies allow users to require that certain scans are run as part of the project pipeline. Currently requiring SAST, Secret Detection, Container Scanning, and DAST scans is supported. In addition to some usability improvements, the next step is to make these policies available at the Group level.
Security Approvals
We recently introduced Security Approval Policies in the GitLab 14.8 release to replace the functionality previously provided by GitLab's Vulnerability Check feature. Security Approval Policies provide the following benefits over the previous Vulnerability-Check functionality:
As we are planning to remove Vulnerability Check in the 15.0 release, we are currently working on a script to migrate Vulnerability Check rules over to Security Approval policies. This script will run automatically upon upgrade to GitLab 15.0.
We do not currently plan to be a full-featured SOAR solution capable of aggregating, correlating, and enriching events from multiple security vendors. We intend to remain focused on providing security management and security orchestration for the security tools that are part of the GitLab product only.
We plan to measure the success of this category based on the total number of users that interact with the Policy and Alert pages in the GitLab UI.
As this category is new, we are still completing our evaluation of the competitive landscape.
As this category is new, we have not yet engaged analysts on this topic.