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 | Govern |
| Maturity | Minimal |
| Content Last Reviewed | 2024-02-20 |
Thanks for visiting this category direction page on Security Policy Management in GitLab. This page belongs to the Security Policies group of the Govern stage and is maintained by Grant Hickman ([email protected]).
This direction page is a work in progress, and everyone can contribute. We welcome feedback, bug reports, feature requests, and community contributions.
/label ~"devops::govern" ~"Category:Security Policy Management" ~"group::security policies".
We believe everyone can contribute and so if you wish to contribute here is how to get started.
Security Policy Management is an overlay category that provides security and compliance policy enforcement across all the scanners and technologies used by GitLab's Secure and Govern stages. Security Policy Management gives organizations a central location to globally enforce policies to achieve a few core jobs:
GitLab was recently named as a Challenger in the 2022 Magic Quadrant for Application Security Testing. As highlighted by Gartner, "It's not enough to automate the process of scanning. When and how policies are applied, and how exceptions are handled, also needs to be automated to bring consistency and auditability. GitLab provides a broad range of policies and common controls for compliance." With GitLab's Security Policy Management, you can leverage automation to efficiently improve your security posture and gain some clarity amidst the chaos.
Security policies allow users to use a single, simple UI to define rules and actions that are then enforced. Two types of policies are currently supported: scan execution policies and merge request approval policies. Security policies themselves are fully audited and can be configured to go through a two-step approval process before any changes are made. All policies are supported at the group, sub-group, and project levels.
Scan Execution Policies allow users to require vulnerability scans to be run, either on a specified schedule or as part of a pipeline job. Currently we support requiring the execution of SAST, Secret Detection, Container Scanning, Dependency Scanning, and DAST scans. We do not plan on adding support for License Compliance as its functionality is planned to be merged into Dependency Scanning (now supported for SaaS behind feature flag). We do intend to add support for Fuzzing; however, this is not on our near-term roadmap.
Merge Request Approval Policies allow users to enforce approval on a merge request when policy conditions are violated. Currently criteria related to both security and license scanners are supported. For example, users can require approval on merge requests that introduce newly-detected, critical vulnerabilities into their application. Additionally, you may enforce and override particular project settings, such as blocking push/force pushing and ensuring that approvals are now allowed by a merge request author or committer on the MR.
Security approvals allow users to 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 an eligible user approves the MR. This extra layer of oversight can serve as an enforcement mechanism as part of a strong security compliance program.
Security approvals are a type of merge request approval policy and can be configured in the Security & Compliance > Policies page.
License approvals allow users to select the conditions that must be met to trigger the license approval rule, including which licenses are expressly allowed or prohibited from being present in the MR. If all conditions are met, then the merge request is blocked unless an eligible user approves the MR. This extra layer of oversight can serve as an enforcement mechanism as part of a strong legal compliance program.
License approvals are a type of merge request approval policy and can be configured in the Security & Compliance > Policies page.
The traditional approach to application security was to enable scanners, detect all the vulnerabilities, then have AppSec triage vulnerabilities in a vacuum. Triaging large volumes of vulnerabilities is too noisy. It's a significant effort to identify what is actionable, filter out false positives, and determine when dependencies can be fixed and when the security or compliance team needs to be engaged to support.
In addition to this outdated and siloed approach, companies are required to navigate toolchain sprawl, connecting many different systems while creating controls at each different connection point. The more tools one has, the more connections are required and the more fickle they are to manage and secure.
GitLab offers a complete DevSecOps platform as a single application with integrated security and compliance controls that ensure visibility, auditability, and enforcement across the SDLC. This modern approach builds Security into the process and encourages collaboration, increasing velocity and improving innovation. And, while other solutions require you to stitch together tools and create complex systems to enforce policies, GitLab's Security Policy Management enables organizations to maintain global oversight while establishing the separation of duties between security, compliance, legal teams, and engineering departments. Security Policies feature also grants development teams a level of flexibility over their processes that ensure stable, reliable, and quality production-quality code. As businesses typically struggle with troubling gearing ratios between software engineers to security engineers (20:1 or worse), GitLab's tools can help enterprises automate and manage security and compliance risk at scale.
GitLab's Security and Compliance Policy Management covers the many touch points across the DevSecOps platform to reduce risk and allow the business to operate efficiently. The top-level themes that will help our customers succeed are:
See our prioritized roadmap here.
We're working to mature our support for enforcing custom CI across projects. While today we have an experiment – the Pipeline Execution Action for Scan Execution Policies, based on customer feedback we will be releasing the new capability within a new policy type – the Pipeline Execution Policy type. This new policy type will support custom CI YAML input, which may be configured in a remote compliance yaml file and managed from the policy.yml.
As we mature these features we are adding the following capabilities:
Additionally, we're working on:
We do not 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 are also not planning to support Network Policies (Container Host Security and Container Network Security). We previously offered this capability but learned that challenges related to GTM, pricing & packaging, and personas led to low adoption. This required a shift in our strategy. More details around the decision can be found in this internal issue.
In the long-term, we intend to add support for additional policy types, including Vulnerability Management, Compliance, Insider Threat, and Pipeline Execution policies. Furthermore, 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.
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. It will also provide an interface for security and compliance teams to review and respond to policy violations that have occurred.
The matrixes below describe the scope of the work that is planned in the long-run for the Security Policy Management category as well as our progress toward the end goal. Our long-term vision is to add support for all of the boxes in the table.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
Security Policy Management enables global control of settings across an organizations technology assets and can extend to the processes and procedures used to enforce particular policies.
For GitLab, our focus is on supporting DevSecOps personas, which specifically involves AppSec, Security Operations, Compliance, and InfraSec personas. Each of these users is tasked with ensuring a business' applications are secure and compliant by preventing or reducing the risk of introducing vulnerabilities into production code and live applications. This involves securing each step of the SDLC as well as ensuring proper access and compliance within GitLab itself.
The most critical capabilities for a best-in-class DevSecOps Policy Management solution are as follows:
Security Policy Management at GitLab is in a category of its own. It's not currently possible to fully orchestrate the enforcement of security policies across the entire Software Development Lifecycle in the way you can with GitLab. Often, enforcing security and compliance requirements requires identifying endpoints across many tools in your software toolchain and creating custom solutions to instantiate controls that you must maintain.
With GitLab Security Policy Management, we offer global enforcement of policies across the groups, subgroups, and projects in your GitLab instance (or namespace in the case of GitLab.com). GitLab is responsible for maintaining the UI and YAML editor that can be leveraged to create and enforce policies, and we continue to build more capabilities to optimize and simplify management for diverse use cases, which mitigates further development efforts to manage customization of policy logic.
While we offer a competitive solution that reduces toolchain complexity and eases global enforcement, some of our competitors have offerings with comparable functionality.
We have a very competitive position against GitHub regarding policy management. We offer a UI for intuitively defining custom policies, in addition to YAML mode for advanced users. We're expanding to make group and organization-level management of policies a breeze across large organizations while increasing the accuracy and confidence in the enforcement of policies. GitHub offers a very basic solution for checking vulnerabilities and blocking the merge of a PR but lacks the depth as well as the strategic investment to solve this holistically for Enterprise customers.
GitHub includes the following capabilities today:
There are prerequisites to utilizing GitHub, however:
Synopsys offers Intelligent Orchestration, which allows users to optimize pipeline usage, in turn reducing pipeline costs and potentially impacting developer velocity due to optimizing pipeline duration.
However, leveraging Synopsys requires integration with your CI/CD and maintaining enforcement across the toolchain.
More details about Govern's Best-in-class position are captured in our internal handbook.
Security and Compliance policies are capabilities that serve the needs of Large, Ultimate tier customers, Mid-market customers, and customers working in highly regulated industries/sectors such as PubSec, Healthcare, and Financial Services.
All features under Security Policy Management target Ultimate-tier customers.
GitLab offers a simple pricing model based on monthly seats. Ultimate tier customers gain access to more powerful tools that unlock the power of DevSecOps, including Security Policy Management, Security Dashboards, Dependency Scanning, DAST, Fuzzing, and much more.
We are beginning to engage analysts on this topic, but do not currently have research to provide.