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-06-30 |
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 group much like you would a regular merge request approval group. Then, when merging to the default branch, if a vulnerability with severity of Critical, High, or Unknown is present, the merge 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.
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 are currently behind a feature flag and are actively under development. The first iteration will allow users to require that certain scans are run as part of the pipeline. We are planning to set the feature flag to default to on in the %14.1 release, which will enable support for DAST policies. We also plan to introduce support for Secret Detection policies shortly afterwards in %14.2.
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.
