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 | Security Risk Management |
| Maturity | Minimal |
| Content Last Reviewed | 2024-01-14 |
Thanks for visiting this category direction page on Security Policy Management in GitLab. This page belongs to the Security Policies group of the Security Risk Management 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::security risk management" ~"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 enables security and compliance teams to manage and mitigate risk at scale through vulnerability management workflow automation, DevSecOps configuration automation, and tools for ensuring security by default.
Security policies empower AppSec teams to effectively and efficiently adhere to organizational security standards at scale.
Additionally, the Security Policies group supports the underlying framework for enforcing default settings and configuration, ensuring vulnerabilities cannot be introduced through misconfiguration throughout the DevSecOps lifecycle.
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. Four types of security policies are currently supported:
1) Scan execution policy 2) Pipeline execution policy 3) Merge request approval policy 4) Vulnerability management policy
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, and you can enforce policies across your entire GitLab instance or namespace.
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.
Pipeline Execution Policies ensure enforcement of custom CI within project pipelines, allowing for enforcement of customized GitLab security scan templates, 3rd party security scans, and custom CI scripts/jobs that support security and compliance use cases.
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. Merge request approval policies have support multiple different rules: Security approvals, License approvals, and Compliance Approvals (via the "Any merge request" option). Vulnerability Management Policies automate workflows for AppSec professionals, ensuring they can more efficiently narrow down and identify actionable vulnerabilities across their organizations assets. This policy type initially supports "auto-resolve" capabilities for filtering out vulnerabilities that are no longer detected and automatically marking them as resolved.
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.
By selecting "Any merge request" in the policy rules, you can enforce approvals on any merge request, regardless of any security scan or license results. This allows for enforcement of the "four eyes principle", which ensures that no code changes that will ultimately end up in a production environment can be merged without approval from at least two different people. Compliance requirements may vary, but this policy rule allows for enforcement of one or more approvals on a merge request that meets the specified criteria.
As businesses typically struggle with inequitable gearing ratios between software engineers and security engineers (20:1 or worse), GitLab's tools can help enterprises automate and manage security risk at scale.
In spite of the size of an AppSec team compared to the number of applications they are responsible for securing, there are many challenges these individuals must overcome, which are ripe for automation and optimization via Security Policies and the broader suite of GitLab tools:
Moving into 2025, Security Policies will have a heightened focus on simplifying and automating the process of triaging and resolving vulnerabilities. Security policies are a common feature found throughout AST and ASPM tools and help AppSec teams to translate their model for security risk into an engine for more efficiently identifying risk and prioritizing actions to take.
GitLab Security Policies will build on top of our existing capabilities to further accelerate AppSec teams' productivity, to enable policies gracefully across an organization at scale and reduce the vulnerabilities that poise the greatest risk.
Primary Themes for Security Policies include:
1) Continued improvement of Pipeline Execution Policies 2) Increased AppSec efficiency through Vulnerability Management Workflow Automation 3) Security Policy platform capabilities to enable GitLab teams
Pipeline execution policies continue to be a powerful feature for Enterprise customers as they allow for broad enforcement of custom CI throughout an organizations project's. Pipeline-based enforcement helps address numerous use cases for customers across multiple areas from Application Security Testing (enforcing customized GitLab security scans, 3rd party security scans, custom scanning rules), Application Security Posture Management (auto-remediation workflows, monitoring), Software Supply Chain Security (separation of duties, pipeline protections), and Compliance (enforcement of pipeline-based compliance checks/rules, reporting scripts).
As we sunset Compliance Pipelines, we continue to expand on our capabilities for Pipeline Execution Policies to address more of these use cases in a stable and long-term implementation.
As part of our focus on increasing AppSec efficiency, we're working on introducing new capabilities for automating vulnerability management workflows. This will help security teams more efficiently triage and resolve vulnerabilities at scale.
Key initiatives in this area include:
Auto-resolve policies: Automatically resolving vulnerabilities that are no longer detected in more recent scans.
Auto-dismiss policies: Automating the dismissal process of vulnerabilities based on certain attributes like directory, file path, and identifier. This policy could further be extended to dismiss low-severity vulnerabilities in non-critical projects, dismiss vulns for specific vulnerability classes, and automatically dismissing known false positives.
Auto-remediation policies: Automation policies that update dependencies with known fixes by bumping versions and generating MRs to test success, applying pre-defined patches for common vulnerabilities, and/or triggering remediation scripts globally for common issues effecting multiple repositories.
Additional tuning and policy actions within MR Approval Policies: New tuning options to more efficiently automate triage and new actions to facilitate where in GitLab the vulnerability data is actioned by AppSec teams and Developers. These improvements include:
Workflow automation integrations: Automated GitLab ticket creation, notification generation for critical vulnerabilities/findings, to relevant team members through collaboration platforms, custom workflow triggers that can be used for integration hooks.
Tighter integration with GitLab features, such as Merge Requests (MR widgets/Reports) and Pipelines (better visibility into security policy effects): By building more seamless integration into these GitLab features, we can reduce confusion, reduce false positive policy violations, and help AppSec and Development teams move more quickly with confidence. Key activities here include:
By implementing these automation capabilities, we aim to significantly reduce the manual workload for AppSec teams, allowing them to focus on more strategic security initiatives while ensuring consistent and efficient vulnerability management across the organization.
The final theme of prioritization for Security Policies is both foundational as well as forward-looking. Within this category, we'll ensure that all existing Security Policies, as well as new planned vulnerability management policies, operate in a seamless manner with a modern and intuitive UX that rivals available AppSec tools in the marketplace.
It's important and critical that it's easy for users to get started with GitLab Security Policies regardless of their frame of reference, whether their previous experience is with standard AST scanners, ASPM tools, or if they have a DevSecOps background. In this theme, we will build on our existing framework but will be willing to break the mold to introduce new concepts and simplify the experience.
Key capabilities here include:
As we do work within a platform, it's also important to capture and track any cross-functional areas and plans or opportunities for collaboriation. Our key areas of collaboration include:
See our prioritized roadmap here.
After introduction of pipeline execution policies in 17.2, we are adding new capabilities to ensure flexibility and better support less common use cases supported in compliance pipelines today. We are working to ensure seamless migration from compliance pipelines to pipeline execution policies for security and compliance use cases.
Improvements we are actively working on include:
needs statements for jobs executing in the .pipeline-policy-pre stageWe 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 do not plan 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.
We are not building a workflow engine for broad automation use cases in GitLab, but are focused on security policies that improve efficiency and achieve outcomes for AppSec teams.
While we see opportunity to improve the security and compliance posture of GitLab as a whole across the DevSecOps lifecycle, our group will not be responsible in the short-term for development of any new policies that do not benefit the AppSec persona directly (beyond continued support of pipeline execution policies). Long-term, we plan to provide more capabilities and support to aide in development of policies in these and other areas. Examples include:
And lastly, we are no longer focused on the wide scale enablement and configuration of security scanners, rather this direction will be matrixed to the Security Platform Management group.
Long-term, as part of the Security Risk Management stage, we aspire first to:
Provide an Enterprise-ready solution for automating prioritization, triage, handling and reporting of vulnerabilities that fully supports our Application Security Testing offering.
Enrich vulnerability / dependency data via additional metrics and security parameters for improved prioritization and triage.
Use the power of GitLab as platform to enhance prioritization, leveraging AI and creating inuitive workflows for automated triage and remediation. Examples may include:
Combined with efforts across other groups in our stage, we plan to offer a robust AST offering that is deeply integrated within our platform and ensuring seamless consolidation, enablement, and management of security scans and findings/vulnerabilities through a single pane of glass.
In the future, Enterprise users will be able to simplify the process of creating global policies across their organization (from the Organization layer in GitLab), to manage security and compliance risk with ease, to gain insight into the health status of their organization, and to granularly enforce policy rules only where it's appropriate for the business.
We'll further improve upon the user experience of policies by reducing reliance on the policy.yml and reducing the number of steps required to create a policy (while maintaining benefits of policy-as-code).
As we work to mature our Security Policy Management category, we'll be providing additional support for gauging the impact (blast radius) a policy will have before it is deployed. Audit mode will give teams a method to roll out policies and observe before enforcing. Impact assessments will help users understand how many projects will be impacted and expected behavior before enforcing a policy.
We'll work cross-functionally with teams in GitLab to provide more visibility into how policies are applied and affect other features, such as how policies may affect project settings or modify behaviors in pipelines.
We'll also work to improve context and onboarding, making it easier to enable policies by default through compliance frameworks, or identify where policies should be applied.
Integration between security policies and our compliance features (including compliance frameworks and standards adherence reporting) will continue to bridge the gap between compliance observability and reporting and security and compliance enforcement. Policies can be enforced against projects, linked up to compliance reporting, and used to remediate compliance violations. By leveraging security policies, alongside GitLab compliance features.
For each policy type, we'll work to provide deep capability that helps users filter and customize rules to address most common use cases and requirements for security and compliance enforcement.
As we achieve goals around AST and vulnerability management workflow automation, we'll work to further extend security policy capabilities by establishing a framework that facilitates development of policies across the DevSecOps lifecycle, where GitLab groups across the platform can contribute new policies that can be managed centrally/globally and through a consistent and flexible UX catered to security/compliance personas.
Policies then will continue to grow to become more sophisticated and intelligent, leveraging the insight of an integrated DevSecOps platform to make decisions and enforce behaviors efficiently, contextually, and non-destructively. Policies will ensure that security and compliance are met globally, while increasing rather than disrupting velocity.
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.
Primary:
Secondary
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.