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 | Govern |
| Maturity | Minimal |
| Content Last Reviewed | 2022-07-08 |
Thanks for visiting this category direction page on Security Policy Management in GitLab. This page belongs to the Security Policies group of the Govern 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::govern" ~"Category:Security Policy Management" ~"group::security policies".
We believe everyone can contribute and so if you wish to contribute here is how to get started.
Security Policy Management 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 Govern stages. The goal is to provide a single, unified user experience that is consistent and intuitive.
The work done in the Security Policy Management 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. Two types of policies are currently supported: scan execution policies and scan result policies. Scan execution policies allow users to require vulnerability scans to be run, either on a specified schedule or as part of a pipeline job. Scan result policies allow users to enforce approval on a merge request when new vulnerabilities are detected in the code, or when other security-related criteria is met. 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.
Although this category is new, our vision is broad. We plan to support both scan schedules and scan result 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.
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 the GitLab 15.2 release we made scan execution policies available at the group and sub-group levels. Next we plan to extend that group and sub-group level support to scan result policies as well. Once that is complete, we will shift our focus to add support for Dependency Scanning and SAST and Secret Detection custom rulesets.
A full list of our near-term priorities is kept up-to-date on our open priorities issue.
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.
This category is currently at Minimal maturity. A plan has been created for the category to progress to Viable maturity.
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.