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.
|Content Last Reviewed||
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 (email@example.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".
Security Orchestration is an overlay category that provides policy and alert 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 two key areas: Security Alert Management and Security Policy Management.
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 Instance, 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.
Our first release to bring this category to a Minimal maturity level is scheduled for %13.9 where we intend to release a Security Alert Dashboard. We intend to quickly refine and add to that initial release in the %13.10 iteration with numerous UI improvements.
Additionally, we plan to create a cross-stage Policy Management UI, beginning with adding support for managing DAST scan schedule policies at the project level. 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.
Security Alert Management Designs (for initial release)
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.