This is a high-level epic that tracks related issues and nested epics in service of building a ~"devops::manage" ~"group::compliance" `Dashboard` ## Statement We want to build an experience within GitLab that enables [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/product/personas/#cameron-compliance-manager) to manage the compliance posture of their GitLab groups and projects. This experience should reduce the amount of time they spend looking for or reporting on relevant data. It should also enable them to easily see when problems arise and help proactively remediate audit gaps by providing guidance or other insights for their namespace's compliance posture. The **Compliance Dashboard** should provide a single place to complete all of the identified jobs [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/product/personas/#cameron-compliance-manager) needs to do. ## Use Cases ``` [To do] Replace with JTBD Statements and re-frame use cases as sub-jobs ``` 1. I'm an `admin` or `group owner` at a compliance-minded organization who needs to see all relevant project activity so that I can make data-informed decisions about our compliance posture and take actions to remediate gaps. 2. I'm an `admin` or `group owner` at a compliance-minded organization that needs to walk an `auditor` (internal or external) through my GitLab projects to show them how they are configured so that I can demonstrate compliance and reduce the amount of remediation work required of our team during the audit. 3. I'm an `admin` or `group owner` at a compliance-minded organization that needs to easily aggregate relevant data about projects, MRs, or other data points so that I can export that data as an evidence artifact for an `auditor` or audit. ## Strategic Importance The biggest cost associated with a compliance program or external audit is the sheer amount of time required to identify the scope of the audit (systems and resources subject to the audit), collect all of the information related to those systems and resources, and generating evidence artifacts to provide to an auditor. Microsoft recently released their [Compliance Manager](https://techcommunity.microsoft.com/t5/microsoft-security-and/announcing-general-availability-of-microsoft-compliance-manager/ba-p/1679846), which aims to simplify the process of implementing controls and reporting on those controls for customers. #### Biggest Opportunity GitLab _should_ strive to reduce the amount of time and effort involved with audits and compliance management. There is an opportunity still un-addressed to provide a "Virtual Auditor Assistant" experience. We have an opportunity to build out the Compliance Dashboard to serve as that auditor assistant to remind customers of upcoming audits (they specify), tasks to be completed (ranked on complexity or time to resolve), and guidance for strengthening the audit posture of their projects. There's also an unmet opportunity to consolidate the various, relevant compliance data points from across GitLab - e.g. from ~"devops::secure" ~"devops::defend" and ~"devops::release" - at a high-level to inform regulated enterprise about the tactical actions they need to take to remediate gaps and leverage the strength of GitLab's unified application for devops. #### Biggest Challenge Headcount. The vision for GitLab's Compliance Dashboard and overall Compliance strategy will largely depend on our ability to scale the team and spike on these critical features and experiences. ~"group::compliance" currently consists of 11 people total, of which 7 (3 BE, 2 FE, 1 PM, 1 PD) are dedicated solely to this group and not split amongst other groups. If our group does not expand, we should set appropriate expectations about what's achievable within the next 2 years, when the market is likely to shift and introduce new, innovative solutions for Compliance. If we can expand our group, we can be more ambitious with our vision for the future in that same 2 year timeframe and even attribute some capacity to additional big, hairy, audacious goals that could help future-proof GitLab's Compliance strategy. ## Cross-Stage/Group Collaboration In a [recent discussion](https://youtu.be/aq7xuaWFD5o) with @jmeshell, we discussed a few areas where ~"group::compliance" and ~"group::release management" could collaborate on solutions. A few notable examples: * [CI/CD Dashboard](https://gitlab.com/gitlab-org/gitlab/issues/199739) * The data collected and reported here could be summarized and/or represented in the `Compliance Dashboard`. This fits the theme of our **Statement** above. * There is an [existing issue](https://gitlab.com/gitlab-org/gitlab/-/issues/208946) to determine how to aggregate specific data from the project-level to the group dashboard. * [Runbooks MVC](https://gitlab.com/gitlab-org/gitlab/issues/9427) * Runbooks could interface with https://gitlab.com/groups/gitlab-org/-/epics/2890 very well and make for a great, automated experience for compliance-minded organizations. * [API for reading Secure scanner configurations](https://gitlab.com/gitlab-org/gitlab/-/issues/249369) * We've been collaborating with ~"devops::secure" to find ways to surface specific Security data in the Compliance Dashboard, such as a boolean representation as to whether security scans are `enabled` or `disabled` * [Custom compliance framework project labels](https://gitlab.com/gitlab-org/gitlab/-/issues/231247) * After releasing static [compliance framework project labels](https://docs.gitlab.com/ee/user/project/settings/#compliance-framework), we identified opportunities where ~"devops::secure" and ~"devops::defend" could leverage these labels to perform other functions. * e.g. Define a custom `SOX` label that would require any project using that label to run `scan 1` and `scan 2`. The Secure and Defend teams could then run reports against these labels rather than scanning the entire GitLab namespace, which is less performant ## Prospective Users * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/product/personas/#cameron-compliance-manager) ## Requirements This Compliance Dashboard should provide insight into project compliance, anomalous activity, and a summary view of key compliance data points (to be defined). Examples of data points to report on: - Merge request approval settings - Security scanning dependencies with each deploy - Specific tests with each deploy - The results of pipelines - License compliance data - MRs that were not approved or rejected for `reasons` ## Assumptions to investigate * The dashboard should support "auditor walkthroughs" in terms of customization and data manipulation * Alerting should be baked into the dashboard to provide warnings about items that may bring the project or group out of compliance and require attention * Appending the evidence artifacts to corresponding GitLab Issues (e.g. Attach exported `project evidence`, from the compliance dashboard, to `Issue 123 - SOX X.Y.Z - Title of Control/Requirement`) so they are "more permanent" and belong to the team or project, not an individual (local download) ## Technical Background from @mattgonzales Our vision for this dashboard is to solve for the three primary user stories we've identified with customers (**Use Cases** section above). Towards these ends, there are several [iterations](https://gitlab.com/groups/gitlab-org/-/epics/2768) we can make to support these use cases. This feature could be broken down into several phases: - [x] Phase 1 - [ ] Phase 2 - [ ] Phase 3 - [ ] Phase 4 - [ ] Phase 5 <details> <summary>Phase 1 - Complete</summary> **Phase 1** Provide a [project tagging mechanism](https://gitlab.com/gitlab-org/gitlab/issues/118671) (via Project Topics or other) to let organizations label their projects that are subject to specific compliance frameworks. This tagging mechanism should clearly identify a project as being compliant with `SOX`, `PCI`, `HIPAA`, or other frameworks. Allowing customers to tag projects in this way enables GitLab to provide framework-specific views within the compliance dashboard, enforce strict project settings based on topics, and track or report on compliance status relative to a specific framework. </details> **Phase 2** Surface additional data points that have been communicated as "important to see" in an aggregate or overview context. These additions could be: - [x] [Pipeline results](https://gitlab.com/gitlab-org/gitlab/-/issues/209029) - [x] [Add the MR author to MR's list on the compliance dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/218567) - [x] [Add MR approval settings to Compliance Dashboard](https://gitlab.com/groups/gitlab-org/-/epics/3326) - [x] [Add source and destination branch data to Compliance Dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/216279) - [ ] [Add repository storage location to Compliance Dashboard projects view](https://gitlab.com/gitlab-org/gitlab/-/issues/241984) - [ ] [Denied licenses](https://gitlab.com/gitlab-org/gitlab/-/issues/209241) - [ ] [Security scan results](https://gitlab.com/gitlab-org/gitlab/-/issues/208971) The dashboard should provide a single, consolidated view of a group's projects so an `admin` or `group owner` can make quick decisions about actions that may be necessary. While this data already exists (making it relatively easier to implement), there isn't currently a view with all of this information in one place for an entire group. Adding this data to the compliance dashboard can significantly reduce the administrative overhead of ~"Category:Compliance Management" within GitLab. **Phase 3** We can provide the ability to link [custom compliance framework labels](https://gitlab.com/gitlab-org/gitlab/-/issues/231247) to project templates. Customers can create a project template for `SOX`, which could store the values of the various settings and configurations. They could then associate the `SOX` custom compliance label with that project. When they apply the `SOX` label to other projects, those projects would inherit the values of those settings. This would enable GitLab to have a baseline to report on to show a project's compliance relative to a company-defined standard. This will let us drive adoption of these features to position GitLab for a large push around compliance framework-specific compliance assessment. **Phase 4** With a growing dataset of information to provide to `Admins` and `Group Owners`, we can focus on the third use case of helping them sort and filter the data they need to export to provide as an evidence artifact to an auditor. We could evolve the various dashboard views (MRs, projects) to allow users to define things like: - Filter `Projects` to show only `SOX` projects that were `created` in the last `6 months` - Filter `MRs` to show only `PCI` projects that had `at least` **`1`** `failed` pipeline in the last `12 months` - Sort `Projects` by the number of `commits` in a `24 hour` period We can **reduce overhead** by making these search criteria could be favorited or bookmarked for later use since many searches may be repeatable. The compliance dashboard can reduce the overall time (and cost) of an audit if we build out these features. **Phase 5** Using all of the foundational elements we've built, we can start drawing associations between compliance framework labels and specific compliance controls. For example, we can start to provide _insights or guidance_ (read: not attestation) that "Your `SOX` labeled projects have a 75% compliance score. Several of these projects are missing `{ setting }`, which ties to SOX - Section 404". Additionally, we could provide _guidance_ such as "If you increase the minimum required approvers from `2` > `4` in `SOX` projects, you can increase your compliance score by `5%` as this is better aligned with `SOX Section 404`". _Note: These are examples and not fully vetted for accuracy._ ## Long term design vision |[See Figma for frames →](https://www.figma.com/file/3o57bu6m4O89KkOe4GHP9O/and-2537-Compliance-Dashboard-Vision?node-id=1133%3A5378) |---| || :tv: [UX Showcase: Where is Compliance Management today (2020-10-15)](https://youtu.be/qy8d18GHLoQ?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz)