Last Reviewed: 2020-02-07
Thanks for visiting this direction page on Audit Events in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the corresponding epic for this category.
“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. A key component of compliance is knowing what your users are doing. A universal requirement for legal and regulatory compliance frameworks is the need for reliable, secure, and performant audit logging capabilities. In order to manage, or prove, compliance you must have visibility into all of the activity within your GitLab environment.
GitLab is an application used by people. These users interact with shared resources like projects, comments, and groups. Administrators, especially in complex instances with high levels 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 they’ll be able to have the information needed to answer critical questions. 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. Separation of duties 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 compliant with company policy. 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.
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 Events is viable. Here’s why: GitLab currently offers an audit log system, but it does not capture 100% of user-driven events. While we’re iterating and capturing more events over time, our users demand a comprehensive view of activity in application logs. However, the events being captured are useful at answering valuable questions on GitLab instances, and are used to solve real problems.
Advancing this category to a complete state means 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 the history behind nearly any change. Additionally, these audit logs should be usable; an administrator should be able to ingest them into their SIEM tool of choice or search for events easily in the GitLab UI and via our API.
Lovable consists of compliance adding active monitoring for Audit Events to be 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 viably mature, we’re pursuing completeness and transparency by adding additional activities to our audit logs. You can view the Audit Events complete maturity epic here.
This vision is a work in progress, and everyone can contribute:
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.