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-04-28 |
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.
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.
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. The next few incremental improvements that we have planned are as follows:
Our initial security policy management work has been started and is available behind a feature flag. Users can currently require DAST scans to be run anytime their project pipeline is run. The next steps are to also allow enforced scans to be run on a regular schedule and also to create a user-friendly UI for managing these security policies. This initial work will allow us to build a framework that we can then extend to other scanners, and also extend to the group and instance levels.
Our first step for security approvals is to research how we can iterate toward our end goals of having the capabilities tightly integrated with 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.
