Thanks for visiting this category page on audit management in GitLab. This page belongs to the Access group of the Manage stage, and is maintained by Jeremy Watson.
This vision is a work in progress, and everyone can contribute:
“Compliance” is a term that evokes images of a large and slow-moving organization, but every instance with more than one user manages compliance in some way or form. At GitLab, we think of “compliance” as simply managing and knowing what your users are doing. Whether you’re collaborating with a couple of contractors on a small CE instance or managing thousands of users for a HIPAA-compliant healthcare company, GitLab should be able to provide the controls and traceability that your instance needs to be successful.
GitLab is an application used by people. These users interact with shared resources, like projects, and with each other in comments and groups. Administrators, especially in instances with tons of activity and membership, want to ensure that user-driven changes are adhering to the rules - and that they have the ability to see and backtrace activity if an event requires further investigation. If we’re not offering a comprehensive set of logs, instances won’t be able to feel confident that they’ll be able to have the information needed to answer critical questions when the unexpected occurs. Activity in GitLab should be fully transparent to administrators.
Building on the need for transparency, it’s equally important that we’re presenting information in a way that makes answering questions simple. It’s frustrating to comb through logs. Separations of concerns questions like “who opened and merged this MR?” aren’t readily addressable in a logging system that logs individual events. GitLab’s approach should promote traceability; when a change is logged, we should enable an administrator to see the full context around the change.
The best guard against undesired events, however, is to actively guard against them. For most organizations, being overly permissive and reacting to threats and events just isn’t an option. This problem is doubly challenging, since internal rules and processes may differ radically from organization to organization; any system that provides configuration here must have flexibility. Some instances may want to resolve threats automatically (e.g. by locking a user's account until an administrator can evaluate the event), while others may want to take a lighter touch and simply warn on suspicious activity.
Finally, even with the above problems solved, administrators want to sleep well at night knowing that their instance is secure and fully compliant. There’s rarely a single source of truth that signals to an auditor that everything is OK. Even with logging and a highly configured instance, there’s rarely a resource that an auditor can turn to that provides an easy to understand status on the instance’s compliance status (against an internal compliance framework, or an external one like HIPAA).
Excellence in this category means that we’re solving for all of these needs: transparency, traceability, configuration, and monitoring.
Audit management is a category that touches many areas of GitLab. This includes audit events, permissions, policies, abuse reporting, user management, and others.
To solve the need for transparency, we’ll iterate on the existing audit event system in GitLab to include 100% of user-driven events. Along side enriching our logs, we’ll scale our audit event system to accommodate long retention periods and better support other systems that may ingest these logs, like Splunk and Elasticsearch.
Other problem spaces - traceability, configuration, and monitoring - demand new features.
Since the buyer type for compliance features tends to be a medium to large enterprise undergoing digital transformation, most of the planned additions are targeted at GitLab’s Premium and Ultimate tier.
Currently, GitLab’s maturity in Audit Management is minimal. Here’s why:
Viability for this category is having a robust, complete set of logs that captures the vast majority of user activity. These logs are structured and easily parsed; while GitLab may not actively guard against threats, an administrator can easily track down what happened.
A complete audit management category would allow an administrator to guard against threats by configuring custom policies they can apply to their users. This configuration should be powerful and flexible, allowing an organization to write custom permissions for capabilities they want to protect (or later, permit). GitLab won’t actively warn when a model is breached by suspicious behavior (e.g. data exfiltration), but these configurable guardrails should defuse a majority of problems.
Lovable compliance adds on active monitoring and makes GitLab truly trusted by users. The application is able to demonstrate security and compliance on an ongoing basis in a single view, and actively monitors for (and defends against) suspicious behavior. An administrator or auditor can check a dashboard to be brought up to speed - or simply get some peace of mind.
Since this category is currently minimally mature, we’re pursuing viability and transparency by adding additional activities to our audit logs. You can view the continuous compliance viability epic here.
To be completed. Tools that assist companies with security and compliance range across categories and use cases; these include SIEM tools like Splunk, compliance products for deployed applications like Tigera, and tools that make software auditing easier.
We do not currently engage with analysts in this category.