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||Maturity||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 enable organizationns to define and enforce policies to help them meet their regulatory and business requirements. 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 for achieving compliance to 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 easily view compliance data for groups and projects, define policies to meet business requirements, and optionally enforce workflow steps to meet those requirements. A key goal of the category is ensuring that compliance features do not negatively affect non-compliant teams.
Separation of duties is a core concept among all compliance frameworks and is generally a risk management practice for organizations. Within GitLab, there are many areas where separation of duties is required, such as for merge requests, within CI/CD pipelines, or even changing certain project settings. This is a broad area to cover, but it's also one of the most important requirements our customers have. The implementation of separation of duties features will require collaboration across multiple GitLab product groups to ensure we've covered all of our customers' needs.
Enterprises operating in regulated environments need to ensure the technology they use complies with their internal company policies and procedures, which are largely based on the requirements of a particular legal or regulatory framework (e.g. GDPR, SOC 2, ISO, PCI-DSS, SOX, COBIT, HIPAA, FISMA, NIST, FedRAMP) governing their industry. Customers need features that enable them to comply with these frameworks beginning with defining the rules, or controls, for their GitLab environment.
Compliance-minded organizations are data-informed and need visibility into all of their business operations to make the best decisions. Currently, GitLab does not aggregate the specific information organizations need to make these compliance decisions or monitor compliance status for their groups and projects. The information exists in many cases, but is simply not consolidated and presented in a way that makes compliance a simple, friendly task. Organizations have to dig for information in many disparate areas of the GitLab application and then need to build custom API-driven solutions to extract the data they need for internal compliance management or for reporting to auditors.
Managing large numbers of users with expansive group and project footprints can be difficult to do without the proper insight and tooling. In many cases, customers are building custom scripts or services to enforce things like credential rotation. Credential management is an important element of compliance because the number of people who have access, the systems they have access to, their type of access, and the layered controls in place to mitigate risk of breaches or credential misuse can have far-reaching affects on an organization in the event of a security incident.
In organizations with complex systems and approval structures, there is sometimes a need to bypass an approval flow for emergencies or to override a process that may be particularly burdensome in the moment. These bypasses are normally infrequent, but important. For example, an organization that needs to deploy an emergency fix to their production environment because their website or application is down, and the workflows they've built around deploying that change may require much more time than is available to them.
When organizations adopt GitLab, they are incorporating it into a complex and comprehensive set of systems that are already in operation. These complex systems cover a broad range of functions and exist to support business functions outside of GitLab. Those systems, however, are critical to an organizations' use of GitLab because it could be anything from ITSM to internal reporting systems that generate outputs necessary for the GitLab users to meet company requirements. These systems are involved in the decision process for changes made within GitLab to a production environment. Connecting those systems to GitLab is time consuming, complicated, and comes with inherent challenges since they're not natively supported in GitLab.
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.
The Compliance Dashboard continues to evolve to meet the needs of our customers managing their compliance programs. Our goal is to ensure this dashboard can answer as many questions as possible, saving you the time and effort of digging through individual projects. We want to surface all of the key compliance signals (e.g. segregation of duties, pipelines and project security grades) for you throughout a group so you can immediately, and more efficiently, hone in on the areas that actually require attention.
This dashboard currently focuses on the most recent merged MR and we'll be pivoting to focus on the broader concept of change management. As we focus on compliance management, we want to build features and experiences that enable you to monitor your GitLab compliance posture much easier, saving you time and headache from doing things the traditional way.
The Compliance Dashboard should be the "one-stop shop" for everything compliance teams need to focus their efforts and save time. The more questions we can answer within this dashboard, the less time teams have to spend digging through logs, projects, settings, and other areas.
We will also focus on bringing the credential inventory to GitLab.com to allow managing the credentials that are in use in different groups and projects. This will help group owners to meet compliance requirements and minimize the chance of any credentials being used inappropriately.
Adding coverage for projects to the compliance dashboard means leveraging project compliance framework labels to designate the regulated projects we should track. Currently, the compliance dashboard reports on all recently merged MRs from every project, including unregulated projects. Iterating towards our vision to reduce the complexity and time required of compliance management in GitLab means reducing the total scope of projects you need to monitor in the first place. For those organizations that need only monitor specific, regulated projects, we can surface specific insights about these projects based on your feedback.
Compliance Management will be focused on enabling our users following the SOC2, SOX, and HIPAA standards, because these are the most common among GitLab customers. Additionally, the features we build for these standards will add value to other organizations who are managing compliance with other standards due to the fundamental nature of many requirements the various frameworks share. For example, adding access control features to support HIPAA could potentially satisfy requirements for PCI-DSS.
We'll be introducing better control at the group level by bringing more project settings, such as MR approvals, to the group level. We'll also be augmenting what can be done with custom compliance framework labels, such as letting frameworks be used to manage settings. Compliance frameworks will be defined at the group level and then selectively applied to each project that has specific compliance requirements. This allows for managing group-level setting inheritance and enforcement in a much more tactical way without applying broad controls across an entire namespace.
We will continue to iterate on the Compliance Dashboard to bring necessary compliance context into a single view for easy analysis and action. One of the near term areas we will focus on there is converting the compliance dashboard to show all compliance individual violations, rather than just the most recent ones per project. We are confident this will allow compliance teams to have a better understanding of their compliance posture and take remediation action if needed.
|Compliance Dashboard (Projects)||Compliance Dashboard (Merge Requests)|
Compliance Management is currently in the minimal state. This is because we now have an MVC of the Compliance Dashboard, you can designate regulated vs. unregulated projects and we have some existing settings that serve as compliance controls, but these features are not yet used by significant numbers of users to solve real problems.
In order to bring Compliance Management to the viable state, we will be implementing features that provide GitLab group owners and administrators with more, and better, compliance controls for their GitLab environments. These controls should make it easier to manage compliance within GitLab, such as maintaining separation of duties, establishing clear change control workflows, and preventing changes to these controls by unauthorized users except for emergency or exception situations.
Once we've achieved a viable version of Compliance Management, 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 ruleset 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).