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 | 2023-03-23 |
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 Grant Hickman (ghickman@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 enforcement across 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.
GitLab was recently named as a Challenger in the 2022 Magic Quadrant for Application Security Testing. As they highlighted by Gartner, "It’s not enough to automate the process of scanning. When and how policies are applied, and how exceptions are handled, also needs to be automated to bring consistency and auditability. GitLab provides a broad range of policies and common controls for compliance."
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. Security policies themselves are fully audited and can be configured to go through a two-step approval process before any changes are made. All policies are supported at the group, sub-group, and project levels.
Scan Execution Policies allow users to require vulnerability scans to be run, either on a specified schedule or as part of a pipeline job. Currently we support requiring the execution of SAST, Secret Detection, Container Scanning, Dependency Scanning, and DAST scans. We do not plan on adding support for License Compliance as its functionality is planned to be merged into Dependency Scanning (now supported for SaaS behind feature flag). We do intend to add support for Fuzzing; however, this is not on our near-term roadmap.
Scan Result Policies allow users to enforce approval on a merge request when policy conditions are violated. Currently criteria related to both security and license scanners are supported. For example, users can require approval on merge requests that introduce newly-detected, critical vulnerabilities into their application.
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.
License approvals allow users to select the conditions that must be met to trigger the license approval rule, including which licenses are expressly allowed or prohibited from being 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 legal compliance program.
License approvals are a type of Scan Result Security Policy and can be configured in the Security & Compliance > Policies page.
In the long-run, we intend to add support for additional policy types, including Vulnerability Management, Compliance, Insider Threat, and Pipeline Execution policies. Furthermore, 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.
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. It will also provide an interface for security and compliance teams to review and respond to policy violations that have occurred.
The matrixes below describe the scope of the work that is planned in the long-run for the Security Policy Management category as well as our progress toward the end goal. Our long-term vision is to add support for all of the boxes in the table.
In GitLab 15.10, we introduced IaC Scanning enforcement via scan execution policies.
Next, in GitLab 15.11, we plan on adding support for Role Based Approvers rather than only allowing either users or groups to approve a policy violation. We're also adding more granular criteria for our Scan Result policies, starting with an MVC for more granular status filtering. You will be able to breakdown status options based on newly detected versus previously existing vulnerabilities. We'll then continue expanding support of filters based on the age of vulnerabilities and attributes (false positive, fix available) that will further narrow the focus of your policies on vulnerabilities your team can action.
Once we finish improving our current set of functionality, we plan on consolidating the capabilities of Compliance Framework Pipelines with Security Policies to provide for a single, unified experience. More details on these roadmap plans can be viewed in this video or in the design mocks in this issue.
Additionally, we plan to introduce a new type of policy to allow users to enforce approval requirements for all merge requests independent of security or license scan results.
See a full list of our near-term priorities on our group direction page.
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 the following metrics:
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.
This section was recently moved to the group level Security Policies direction page.
*This 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.*