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-11-29 |
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 is an overlay category that provides security and compliance policy enforcement across the DevSecOps lifecyle. Security Policy Management gives organizations a central location to globally enforce policies to achieve a few core jobs:
Security policies will continue to address core use cases across the lifecycle, such as defining enforcement around CI component usage, blocking risks related to dependency/package management, and automation of vulnerability management workflows to address security and compliance controls.
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, 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.
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).
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.
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.
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 include:
needs statements for jobs executing in the .pipeline-policy-pre stagedefault or .latest security templates when configuring a Scan Execution Policy.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 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 and compliance personas.
In the long-term, we will add support for additional policy types that span the DevSecOps lifecycle, including Vulnerability Management, CI Component Governance, Dependency Firewall, and Insider Threat policies. Security and compliance teams will be able to leverage security policies to create controls that reliably ensure enforcement where it matters most.
See below for a detailed list of opportunities we'll be exploring for security policy types in the long-term, along with the current status of each policy type.
Integration between security policies and our compliance feature (including compliance frameworks and standards adherence reporting) will 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,
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.
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.
We'll also 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.
And lastly, policies 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.
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.