Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Group Direction - Compliance

This page is for the Compliance group. It describes high-level goals and direction for our group. Check out the Manage section page to see what the rest of our stage is working on, how we fit in, and our individual category pages to get fine-grained details.

Compliance helps organizations move faster, not slower

A common misconception of Compliance is that it slows an organization down and is all about telling team members not to do something. In fact, Compliance is about helping organizations move faster. Compliance reduces the risk of mistakes that could cause damange from happening, which means that users are more free to experiment and try new things than they would be otherwise.

Compliance also helps teams move faster because it helps them be confident that once they have completed their configuration, they can rely on and trust it to enforce what they have configured. They no longer need to worry or perform manual checks to continually re-confirm there is not a problem - compliance controls ensure things are behaving as they should. This frees up the team to focus on other activities that can add additional business value.

Compliance controls also help businesses navigate and pass audits successfully. Audits can be very time-consuming, as auditors will require specific records to show that various processes were followed, certain artifacts were produced, and that violations did not occur. Without a robust compliance system, this can be very manual and incredibly difficult to do. Compliance helps organizations provide to auditors what they need easily and quickly, so that they can pass audits without issues. When audits are easier and take less time, businesses are able to focus on continuing to advance their products and services, instead of spending time on gathering artifacts for audits or implementing remediative actions from the audit.

Categories we focus on

  1. Compliance Management
  2. Audit Events
  3. Audit Reports

Compliance, Regulatory Requirements, and Security

Our compliance controls and reporting provide value to any organization, whether they must adhere to regulatory standards or not. At GitLab, we view compliance as a way to help businesses define, implement, and manage policy-based controls for their organization. This helps for meeting regulatory requirements and provides real value by helping organizations manage risk inside their business.

As we develop compliance, our goal is to go well beyond "checking a box" needed for a standard, but to ensure that our capabilities deliver value by protecting the business and reducing risk. We do this by thinking through each of our new capabilities and considering how a malicious actor may try to bypass, circumvent, or disable it. We view compliance and security as very closely related and two areas that must work effectively together. Compliance defines workflow and policy requirements, enforces them, and monitors adherence to them. Security is all about ensuring what is being defined, enforced, or monitored cannot be bypassed, disabled, or modified inappropriately. Having compliance without security or security without compliance means an organization either is just checking a box with a false sense of security or is enforcing arbitrary restrictions, respectively. If we add something that meets a requirement for a standard, but does not prevent a malicious actor from negatively impacting the business, we're not done - we need to do more.

This approach gives GitLab a way to differentiate itself from other compliance tools on the market. Other tools are reactive and help identify blind spots or deviations after they have occurred, while GitLab's goal is to proactively prevent these problems from occurring in the first place. Organizations may view compliance as unneeded overhead for reports, but at GitLab our goal is to ensure our users are safe, the risk to the business is minimized, and that compliance helps the business move more quickly.

Jobs to be Done

To best frame these problems we’ve compiled a set of Jobs To Be Done (JTBD) that represent the jobs our users are hiring us for. If you’re unfamiliar with JTBDs take a look at this article.

Manage compliance posture

When I am responsible for ensuring the compliance of my organization, I want to ensure we meet all required criteria defined in controls and policies, so that it does not create problems for us during an audit.

Job statements Maturity Confidence Source
When restrictions are necessary, I want to configure an environment, so that I can ensure we are compliant. Badge level - Issue
When I have complete visibility into adherence of policies, I want to monitor the condition of our software development practices, so that I can address issues before they become more problematic. Badge level - Issue
When I am preparing for an audit, I want to create shareable deliverables, so that I can provide evidence of compliance. Badge level - Issue

Personas we work with

Cameron, the Compliance Manager, is one of our key personas we focus on. Cameron has many different jobs, such as those listed above, and we want to ensure they can be effective in doing them and making those jobs easier.

We know that Compliance affects an entire organization when policies and business requirements are added. While not our primary personas, we focus on how our capabilities impact others, such as Sasha, Delaney, Devon. Our goal is to ensure those other personas are minimally impacted and can do their jobs while still remaining compliant with the organization's policies. Reducing the friction between the compliance needs of a business and team's needs to get work done will be a key way GitLab can add value for our users.

How we approach problems

The problems and use cases we focus on can be quite large, so it helps to break them down into smaller pieces. As a result we focus on discovering the most minimal viable change possible that still solves a particular problem by trying "boring solutions" first.

Traceability, visibility, and actionability

Use cases we focus on can be broad and could go in many directions. We will focus on approaching these by starting from traceability, moving to better visibility, and then providing actionability. What we mean by that:

  1. Traceability - Give users the raw form of data. This allows them to do post-processing and aggregation on their own. This is a first step, but if we do not ever record low-level data or details, users have no ability to do next steps manually or contribute back to GitLab.
  2. Visibility - Give users aggregations and reports on data. This allows them to quickly see what is going on and what may need to be adjusted. Once they are aware of current state, they can then manually take action to resolve any issues.
  3. Actionability - Act on our users' behalf to enforce the policies or settings they define. This is a final stage that builds on top of traceability and visibility.

This approach is a good, iterative approach since it allows us to enable more users over time, rather than making everyone wait until everything is completed at once. As an example, if we simply record and expose some pieces of data, that enables users that need to implement a policy do so with some sort of custom script immediately. They may even contribute it to GitLab. Over time, we can expand from just reporting that data to offering settings and enforcement around it. This means users that need the capability sooner can get what they need and users we work with later get a complete offering after we have finished.

Where we're headed

The Compliance group handles the three categories listed above and focuses on advancing each of them. This means we will prioritize some before others. This section highlights and stack ranks our main areas of focus as a group. Please note these are the highlights and not a comprehensive list. Each specific category page has additional details on the other epics and issues for the category we are focused on.

  1. Adding new and refactoring existing audit events (epic)
    • One of our users key needs is that our audit event system is comprehensive enough to record all the sensitive activities that occur in GitLab. Because GitLab releases every month, we will focus on adding new events to ensure our customers have the visibility they need.
  2. Webhook-based audit events (epic)
    • Our users frequently wish to view audit events outside of GitLab, combine them with other data sources, and process them in some way. Rather than require users to manually download events from our API, we will deliver new audit events as they occur over a webhook. This way users can listen to the webhook and take any relevant action as soon as a new event occurs. This also is a benefit for GitLab, since it means we do not have to store and manage the potentially millions of events that are generated so can start recording higher-volume audit events that users are interested in, such as Git activity.
  3. Updating and improving the Compliance Dashboard (epic)
    • Compliance teams have limited bandwidth and need to be able to easily find activity that does not follow policy to either remediate or document a variance. We have a great opportunity at GitLab to update our Compliance Dashboard to be even more meaningful for this use case.
  4. Credential inventory for GitLab.com (epic)
    • GitLab users who are self-managed get a lot of value out of our credential inventory system to understand what sort of exposure their instances are, who is using various credentials, and removing access when needed. This has previously only been available to self-managed users, so we will focus on providing this same sort of experience to GitLab.com users, in line with our SaaS first principle.
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license