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 | 2021-09-22 |
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 Alert Management, Security Policy Management, and Security Approvals.
The security alert dashboard provides a workflow for viewing and managing security alerts. Users can configure Network Policies to generate alerts when traffic is detected that matches the policy. These alerts then show up on the security alert dashboard where they can be triaged by a security team.
This is coming soon and is currently available behind a feature flag.
Security approvals are an optional feature for merge requests. You create a security approval rule much like you would a regular merge request approval rule. Users can 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 someone in the security approval group approves. This extra layer of oversight can serve as an enforcement mechanism as part of a strong security compliance program.
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 Alert Dashboard
We recently brought this category to a Minimal maturity level in %13.9 with the release of a Security Alert Dashboard. Since then, we have iterated to refine that experience. We will be temporarily reducing our investment here to focus on Security Policies and Security Approvals, but plan to pick it back up later with an improved drawer design. That experience is currently in the design phase and feedback is welcome.
Security Policies
Security Policies allow users to require that certain scans are run as part of the project pipeline. Currently requiring DAST and Secret Detection scans is supported. Added support for requiring SAST scans is planned for 14.5.
Security Approvals
We are currently working to make Vulnerability Check rules more granular by allowing users to define which scanners and the number and type of vulnerabilities that should trigger an approval condition. Once that is complete, we plan to add support for multiple Vulnerability Check approval rules and merge the management experience into the security policy editor.
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.
