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.
Protecting cloud-native applications, services, and infrastructure
The Protect stage enables organizations to proactively monitor vulnerabilities in cloud-native environments to reduce overall security risk. Protect is a natural extension of your existing operation's practices and provides security visibility across the entire DevSecOps lifecycle. This visibility empowers your organization to apply DevSecOps best practices from the first line of code written and extends all the way through to greater monitoring and protection for your applications that are deployed in production.
The Protect Stage focuses on providing security visibility across the entire DevSecOps lifecycle as well as monitoring vulnerabilities in your cloud-native environment. Protect reduces overall security risk by enabling you to be ready now for the cloud-native application stack and DevSecOps best practices of the future. This is accomplished by:
The Protect Stage is made up of one group supporting the major categories focused on cloud-native security:
The existing team members for the Protect Stage can be found in the links below:
Protect will focus first on providing reactive security solutions that are cloud native. Whenever possible, Protect capabilities will be cloud platform agnostic, including support for self-managed cloud native environments.
For example, GitLab's current Protect capabilities leverage numerous open source cloud-native projects that integrate cleanly with Kubernetes to provide additional security in containerized environments. Any future expansion of security capabilities will come after the cloud native capabilities are mature.
Protect will contribute upstream improvements to the OSS projects whenever possible and practical to help everyone be more secure.
Protect capabilities will be pre-configured with reasonable defaults out-of-the-box whenever possible. When not possible, they will be easy to configure either through code or through a guided UI workflow that is friendly to users without coding knowledge. Regardless of how the capabilities are configured, they will be stored as code for ease of management.
For example, GitLab's security policy editor supports editing policies in both a rule mode and in yaml mode
Protect capabilities will serve as a connection point for a seamless workflow spanning across different types of scanners and also across different features in GitLab. By facilitating data sharing and interoperability across GitLab's features, Protect can help solidify the advantages GitLab has to offer as a single application. For example, these areas might include the following:
Building on those themes, some specific capabilities that we envision developing over the next 3 years include the following:
** Security Orchestration **
** Scanning **
Over the next 12 months, the Protect stage is focused on expanding the capabilities of the Security Orchestration and Container Scanning categories. Some of the key initiatives include the following:
Although we will likely address many of these areas in the future (as described above in our 3 year strategy), we are not planning to make progress on the following initiatives in the next 12 months:
TBD - this area is currently being re-evaluated
The following metrics are used to evaluate the success of the Protect stage:
Note: We are not currently evaluating the success of the Protect stage based on the Security Orchestration category as we do not yet have reliable metrics for this area. The Stage Monthly Active Cluster metric has been temporarily deprecated due to its impact on performance.
GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.
To capitalize on the opportunities listed above, the Protect Stage has features that make it useful to the following personas today.
As we execute our 3 year strategy, our medium term (1-2 year) goal is to provide a single DevSecOps application that enables SecOps to work collaboratively with DevOps and development to mitigate vulnerabilities in production environments.
Security teams are the primarily day-to-day users of Protect features. Over time, GitLab aims to become the primary tool they use to protect, monitor, and manage the security of their production environments. As most organizations have limited resources and/or security talent, we will strive to make the entire user experience as simple and easy to use as possible so as to minimize the skill set and number of individuals required. Additionally, summary-level dashboards and reports will eventually be provided to allow for clear reporting up to executives.
Personas
Protect's Container Scanning and Security Orchestration categories are intended to be used by a wide range of personas, including Software Developers, Compliance Managers, DevOps Engineers, and Security Engineers. To adopt these categories, the only prerequisite is for the user to adopt GitLab's CI pipelines. For Container Scanning, users must also either use GitLab's Registry, or use another external registry, or have a Kubernetes instance connected to GitLab.
Protect is focused on providing enterprise-grade security capabilities to protect production environments. The intent is to provide enough value in paid features so as to allow Protect to contribute in a significant way over the next 3 years toward GitLab's company-level financial goals.
Although paid features are the primary focus, there are several reasons why features for unpaid tiers might be prioritized above paid features:
This tier is the primary way to increase broad adoption of the Protect stage, as well as encouraging community contributions and improving security across the entire GitLab user base.
As a general rule of thumb, features will fall in the Free tier when they meet one or more of the following criteria:
Some examples include:
This tier is not a significant part of Protect's pricing strategy.
This tier is the primary focus for the Protect stage as the security posture of an organization is typically a primary concern of the executive team and even the board of directors. Just as a major security incident has far reaching consequences that impact the entirety of an organization, the features and capabilities that successfully protect against those types of attacks tend to be valued with equal weight. The types of capabilities that fall in the Ultimate tier vs an unpaid tier should be those that are necessary for an organization, rather than an individual, to provide for adequate security of their production environment.
As a general rule of thumb, features will fall in the Ultimate tier when they meet one or more of the following criteria:
Some examples include:
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
Check Docker images for known vulnerabilities in the application environment. Analyze image contents against public vulnerability databases using the open source tool, Clair, that is able to scan any kind of Docker (or App) image. Vulnerabilities are shown in-line with every merge request. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
Unified security policy management capabilities across all of GitLab's scanners and security technologies. Apply policies to enforce scans and to require security approvals when vulnerabilities are found. This category is at the "minimal" level of maturity.
Priority: medium • Documentation • Direction
The Security Orchestration category's features span across multiple stages in GitLab, including the Secure and Protect stages:
The alert dashboard is the central location for viewing and managing alerts. The long-term plan is to aggregate alerts from all categories at the project, group, and workspace levels and visualizing those alerts in both a list-view as well through explorable charts and graphs. Alerts will be eventually be capable of being prioritized based on the severity of the alert (defined by the policy that generated the alert) as well as an analytical algorithm that scores the alert based on its level of risk. The alert dashboard will also host the central workflow for taking action on alerts, including any auto-suggested remediation actions or recommended policy tuning changes.
The policy management experience is the central location for policies across both the Secure and Protect stages. Here users will be able to have the flexibility of managing policies directly in code or in a streamlined UI editor. As part of the long-term vision for the policy management experience, users will be able to view a complete history of all changes and easily revert to a previous version. A two-step approval process can optionally be enforced for all policy changes. Eventually the policy management UI will be extended to provide visibility into the performance overhead of each policy. Suggestions into policy adjustments that might help either reduce false positives or increase overall security coverage will be provided in this section as well.
Security approvals define when and how security teams get involved in the development workflow. The vision for this area is to provide a highly granular level of approval definition functionality at the project, group, and workspace levels. These capabilities will be tightly integrated with the Security Policy editor to allow for separation of duties for security teams.
vulnerability-check to scan_result_policyscan_result_policy as an approval rule functionalityscan_result_policy Ultimatevulnerability-check to scan_result_policyscan_result_policy as an approval rule functionalityThere are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!
Last Reviewed: 2021-04-23
Last Updated: 2021-04-23