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|
Organizations operating in regulated industries have an obligation to report on their compliance. This could be to external auditors, internal auditing teams, an information security team, regulators or executive leadership. These reports usually manifest as evidence artifacts such as logs, configurations, access lists, screenshots and more. The process of finding, aggregating and compiling this information is time-consuming and tedious. In many cases, the person responsible for managing the audit or compliance program doesn't have the expertise, access or tools necessary to build scripts and other services to simplify these tasks. Even if they did, that's still an investment of time away from other value-adding activities.
Comprehensive Audit Reports are necessary to satisfy the needs of an organization managing a compliance program. These reports serve both internal stakeholders like an audit team or executive management; they also serve external auditors conducting the audit. The Audit Reports category seeks to provide you with the tools and features you need to quickly and easily generate audit reports, in a format that works for auditors, out of the box.
GitLab is a large application with many moving parts. This means you need to dig into many projects, audit logs, settings, or other resources to get the data you need as audit evidence. This is challenging, requires a lot of time, and each compliance requirement will need different types of evidence. Taking screenshots, combing through logs and walking an auditor through processes might sound like fun, but in reality, it's an experience full of friction.
Your organization is complex with policies and procedures to follow. Correlating those activities to specific GitLab functionality is difficult. Your auditors will audit your operations against the policies your organization defines. This means the audit can be inherently complex too. Audit Reports should work out of the box for your specific needs. This means the reports should be customizable. Every audit is different and no single report will satisfy 100% of an auditor's questions. You need to be able to customize these reports to suit your auditor and your business requirements.
Audits are about showing an auditor your organization's policies and procedures (what your organization says it's doing) and demonstrating those policies and procedures in action. An auditor will initially scope the policies, procedures, systems, and other areas to be covered and then use this information to guide the audit. If an organization claims that every visitor must sign in and sign out, the auditor will ask to see that process, see the activity in action, and then ask for evidence of that activity happening outside of the audit. These are general assertions since every audit is different.
With the varied nature of audits, GitLab is focused on building a comprehensive audit report that satisfies as many scenarios as we can. We'd like to ensure the audit reports you generate within GitLab contain, at a minimum, the following elements:
In the spirit of iteration, we'll be focused on building MVCs for each of these reports and then leverage customer feedback to determine how best to improve them and consolidate them into a single, thorough report.
We will also focus on how we can collaborate with other groups in GitLab around how existing capabilities could be used in context of audit reporting. One example of this is Runbooks, where we are considering how we could use a runbook to help both auditors conducting an audit follow a standard process as well as help teams being audited ensure they are prepared for the audit.
GitLab will not focus on providing reporting on activities that are done outside of GitLab. For example, we do not plan on pulling data from third-party systems, like HR portals, disaster recovery runbooks, or employee handbooks, to create audit reports.
GitLab will not provide reporting that suggests an organization is fully compliant with a given framework and will instead focus on providing reports that help compliance teams better understand their compliance posture. This in line with our Compliance Toolbox approach, since every individual organization will have unique needs and requirements that are agreed to with its auditors.
GitLab has insight into all of the important data you need to pass an audit with flying colors and with minimal effort invested in collecting evidence artifacts. The problem is this data is not currently aggregated or structured in a way that makes sense for auditors and is not easily discoverable or exported. To solve this, we've introduced an exportable csv for audit events, we will be introducing a similar report for user access, and we will continue to add the additional
Audit Reports listed above.
We've added an option to export instance-level audit events to csv for self-managed administrators, but this leaves a gap for SaaS customers. We now need to focus our attention on bringing feature parity to the group level and project level to ensure all GitLab customers have access to this export functionality for audit events. This will enable all customers to easily export, parse, and analyze the data they need to investigate an incident, provide the evidence artifact to auditors, or analyze specific activity within their instance for compliance management.
We'll be continuing to pursue the issues in this epic to provide a simple, friendlier option for exporting your user data within the UI that doesn't require custom tooling. We've already added the ability to export permissions in self-managed and we plan to add a similar capability to GitLab.com for root groups. This will provide all GitLab customers an exportable report to ensure they can pull this data easily and measure against their access policies and audit requirements.
Compliance-minded organizations are required to trace the chain of custody of any particular change to their production environment. We've introduced an MVC report for this feature and will continue to iterate on it to meet a growing list of requirements from our compliance-minded customers.
Audit Reports is currently in the minimal state. GitLab does not currently provide features that allow for easy export of important data that could specifically serve as evidence artifacts for a compliance program or audit.
Achieving a viable state for Audit Reports means providing at least two basic reports that users can retrieve easily and without custom tooling. We believe this could be a csv export of all audit events for a self-managed instance and a user access report showing all of a user's group and project memberships in a namespace. These can serve as necessary evidence artifacts and empower customers to retrieve this data without building custom scripts.
Advancing Audit Reports to the complete state requires additional export options and add in-app experiences that solve additional problems around audit reporting. Our current plan is to achieve this state by adding additional reports for the following:
To compliment these reports, we believe audit reporting should also be visual to serve as an executive summary for leadership or even for the day-to-day administrators of GitLab. Finding the information you need, and know you have, shouldn't be hard. It should be easy to find, easy to read, and easy to work with. Exporting this data can serve as an evidence artifact for audits, but simply reviewing the data and making data-informed decisions based on that data is also critical. By building a nice, intuitive visual reporting experience we believe we can make managing your audit reports in GitLab a lot better.
We'll know we're on the right track with Audit Reports based on the following metrics:
XebiaLabs is an end-to-end devops orchestration and reporting platform that provides a particularly compelling feature: release audit report. This report is designed to aggregate the most important data about a release so a user can serve this up as an evidence artifact to auditors. To be competitive, GitLab should provide reports like these that save users time and headache from having to find and aggregate this data themselves.
With GitLab's unified data model as a complete DevOps platform, we have the ability to compile reports that are not only great as evidence artifacts, but reports that can provide derived insights to customers such as a group or project's compliance status and relate customers' internal systems to GitLab for a more comprehensive audit report.
Remaining competitive in this space means providing a first class experience for audit reports. Release:Release Management's efforts in Release Orchestration and Ops:Package's efforts in Release Evidence are both great steps in this direction. With additional reporting capabilities and a focus on integrating third-party services, customers' internal systems, and other GitLab reports, we can provide a comprehensive audit report that should do much of the heavy lifting for compliance professionals and auditors.
We've spoken with a few analysts and they have shared similar insights about the opportunities ahead for
Audit Reports. What they've told us:
Audit Reportsis saving a person's time having to check and double-check the report contents. That time could be reallocated to other value-adding activities
Audit Reportsself-service for auditors, alleviating systems administrators from having to perform these tasks, is how the market is moving
What this means for our direction: This analyst feedback is closely aligned with our current direction, particularly with respect to reducing the amount of time Cameron spends finding and generating audit reports, leveraging the data we already generate for this compliance context, allowing Cameron to refocus their saved time on other, value-adding activities, and making
Audit Reports as self-service as possible for both Cameron and their auditor(s).
The remaining opportunities, such as showing upstream compliance framework changes in
Audit Reports, ensuring reporting accuracy, and providing a tangible map of GitLab settings and configurations to specific compliance framework requirements are currently on our minds but are more closely aligned with a 3-year vision. We do not expect to make any substantial changes to our current direction based on this feedback given how closely aligned it is. Our current sensing mechanisms from customers, combined with this analyst feedback, suggests we're currently prioritizing the right aspects of
Audit Reports and on the right timelines.