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
Businesses have regulatory standards they must adhere to as well as internal policies. These policies are designed to minimize risk, maximize product quality, and protect end-users. Historically, ensuring that these policies are reflected and followed daily was challenging. Many times compliance teams, development teams, and others all worked separately, which made it difficult to reconcile all the various requirements that these external and internal standards imposed.
The goal of Compliance Management is to help organizations to understand the state of their compliance. Compliance with GitLab should happen within GitLab and in the workflows that teams already are using. Keeping compliance within GitLab, rather than other tools, enables everyone to contribute and allows compliance to be a collaborative, rather than a confrontational, activity. Compliance Management helps ensure everyone can use GitLab to effectively develop, deploy, and manage applications inside of GitLab while still meeting their compliance requirements.
This category focuses on enabling compliance professionals to identify compliance and busniess requirements, interpet and define them in GitLab, scope which GitLab projects are in scope of compliance, and then gain visibility into their compliance posture through compliance standards reporting.
Compliance Management works hand in hand with Security Policy Management as compliance management tools give visibility into the state of your compliance, adherence across common regulatory standards, and identifies gaps that may need to be addressed. Security and compliance policies then allow compliance teams to implement compliance controls that can be enforced across an organization's GitLab instance.
GitLab frequently gets asked for an "easy button" for compliance. Users want to be able to flip a switch an be compliant with SOX, GDPR, and other standards immediately. Unfortunately, this is not possible for any vendor to provide. Meeting a compliance standard depends on the unique characteristics of a business and what the business's auditors want to see. For example, an eCommerce site will have different auditing needs and required controls than a financial institution, even if both are working on meeting a similar compliance standard.
GitLab recognizes that each of our users have these unique needs and so Compliance Management provides a collection of controls, settings, and workflow enforcements that we dub the "Compliance Toolbox." While no one control is enough to pass a specific audit, using the different individual capabilities in GitLab, an organization can compose and build the controls and workflows they need to meet their own unique requirements to pass an audit. This approach is also beneficial because it allows organizations to opt-in to more and more controls over time, rather than having to immediately enable every control at once.
Compliance is focused on addressing adherence, visibility, and observability through reporting and data sources. We understand that customers gain value by having multiple means of understanding their compliance posture and where to take action.
With this in mind, we're extending our compliance capabilities through a number of themes:
In 16.10, we're extending capabilities within the compliance center for compliance managers to define, edit, and manage compliance frameworks by adding the ability to view security policies that are linked to a given framework. When utilizing the currently experimental security policy scoping feature, you can scope a policy granularly to enforce only on projects containing a particular compliance framework label, or define a specific set of projects to enforce.
For policies scoped to a compliance framework label, we'll surface the policies within the framework view, giving clearer visibility and line of sight into the controls that are built directly into GitLab to enforce compliance and security requirements - especially those relevant to DevSecOps.
Additionally, we'll be building a workflow to aide users of compliance pipelines in migrating and leveraging the new experimental feature "pipeline execution action" within scan execution policies. This new policy feature will enable enforcement of custom CI yaml across development projects, while also providing more tools and logic for ensuring compliance and global enforcement, without the extra hassle. This will be a logical step and improvement of our capabilities for compliance pipelines, while also better organizing our compliance vs policy features for separation of concerns:
These features work hand in hand to close the loop on security and compliance.
To evolve the overall Govern vision, we'll be unifying the capabilities of Compliance Frameworks, Compliance Pipelines, and Security Policies. This enhancement will bring unique advantages offered separately today into a singular implementation via scan execution policies:
For future use cases and development enhancements related to enforcing security and compliance controls, as they may have previously been handled through compliance pipelines, will continue through the
Govern::Security Policies group. Learn more:
We'll be working with Security Policies to transfer ownership of this capability. Status checks operate similarly to existing Scan Result Policies (aka Merge Request Approval Policies). Status checks are able to block merge requests based on a status update via a middleware API (owned/maintained by the customer). They receive responses from a source and allow for implementation of external compliance checks.
Compliance Management is currently in the viable state. You can read more about GitLab's maturity framework here, including an approximate timeline.
Achieving a complete level of maturity will involve collecting customer feedback and evolving the Compliance Dashboard further and ensuring a more complete coverage of group-level and instance-level compliance controls that enable you to confidently and effectively manage the compliance posture of your GitLab environment. Assuming we're on the right track, we'll continue to focus on these areas:
Finally, once we've achieved a rule set that's sufficiently flexible and powerful for enterprises, it's not enough to be able to define these rules - we should be able to measure and confirm that they're being adhered to. Achieving Lovable maturity likely means further expansion of the two dimensions above, plus visualizing/reporting on the state of Compliance Management across the instance.
We'll know we're on the right track with Compliance Management based on the following metrics:
According to the Worldwide Governance, Risk, and Compliance Software Forecast, 2020–2024, the worldwide GRC software market is expected to grow by an average of 4.2% over the next five years to $12.8 Bn in 2024 (Source: IDC DOC #US45856620, SEP 3, 2020). While GitLab does not fit perfectly into the GRC software market, the Compliance group at GitLab aims to build out the features and experiences necessary to provide the same value as these companies and services. Extending the functionality of GitLab to simplify GRC related activities will allow our customers to save time and effort on defining policies, capturing relevant audit data, reporting on the compliance status of their systems and resources, and automating SDLC compliance tasks.
Further strengthening GitLab's position for this opportunity is our inherent design for both a public SaaS option as well as an on-premise/self-managed solution. Providing both options allows us to capture more of this market share, particularly within organizations where public SaaS is not an option due to stricter requirements around air-gapped networks or multi-tenant SaaS solutions.
Even by conservative estimations, if GitLab can capture even 1% of this market, that is $128 MM in revenue that could be captured by building first-class experiences for governance, risk and compliance. By focusing on the themes discussed on this direction page, we believe it's possible to capture portions of this market while ensuring our customers benefit from the time and cost savings of having native GRC capabilities within the GitLab application.
Microsoft Compliance Manager is the most direct competition with this category and our vision for the future. The Compliance Dashboard is moving in this direction, but there are some key differences in each. Microsoft's Compliance Manager provides pre-built assessments for various compliance frameworks or certifications, introduces workflows to complete those assessments or risk assessments, offers "improvement actions" to improve an organization's compliance posture, and generates a compliance score.
After review, our impressions are:
There's an interesting, and valuable, feature that shows Microsoft-managed controls versus customer-owned and shared controls. This would be helpful for identifying where Microsoft needs to take ownership to deliver the controls a customer inherently needs in their service provider.
Microsoft seems focused on building out a comprehensive, natively connected compliance center which is a massive undertaking and commits to a full-on GRC application within Microsoft 365. There doesn't seem to be a specific focus on DevOps, which suggests there's an opportunity for GitLab to provide this focus and supplement other GRC tools that seem to follow a similar pattern.
The feedback we've received about this category has been supportive of our direction to save compliance professionals time and make compliance tasks easier. While there are companies and applications that exist as holistic GRC solutions, GitLab is well-positioned to make a lot of the compliance process easier and automated by enabling customers to leverage the data they're already generating in their usage of GitLab.
We spoken with some analysts about the
Compliance Management direction and here's what they said:
What this means for our direction: The analysts feedback we received is closely aligned with our current direction. The biggest deviation is the emphasis, from analysts, on incorporating compliance data into Value Stream Management. This is not something we're actively pursuing and will re-evaluate. We are currently pursuing some issues, such as a Change Management that will provide some of this data to our customers in the interim.
We've validated most of this feedback directly with customers through our day-to-day work on existing issues and we do not anticipate a significant deviation of our direction for the
Compliance Management category. We will continue to invest in the issues that allow our customers to automate their auditing and compliance requirements, connect their proprietary systems to GitLab, and find the right data in the right places for Cameron (Compliance Manager).