### Problem to solve Compliance-minded organizations rely on services like GitLab to surface insights about their environment to achieve certain goals. A top-of-mind goal for many of our customers is managing the compliance of their GitLab projects. Currently, there's no easy way to determine the compliance status of projects, let alone a way to easily view this status in aggregate. There's no mechanism to identify a project as one that has certain compliance requirements or additional oversight, which is a fundamental need to tracking compliance status. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * All management stakeholders who adhere to any auditing process. For example in a finance institution (Security, Quality, Development department heads) ### Further details The original [discovery issue](https://gitlab.com/gitlab-org/gitlab/issues/36300) for this issue provided valuable insight into our direction and allowed us to determine the better MVC for this feature. Given light of new learnings from our research with customers, we've pivoted this MVC to a more appropriate first iteration. ### Proposal Create a new `Project Setting`, which is a pre-defined list of compliance frameworks, to enable customers to identify projects as compliant with those specific frameworks. The list should initially contain the following frameworks: * `SOX` (Sarbanes-Oxley) * `SOC 2` (Service Organization Control 2) * `PCI-DSS` (Payment Card Industry-Data Security Standard) * `HIPAA` (Health Insurance Portability and Accountability Act) * `GDPR` (General Data Protection Regulation) * ~~`NIST` (National Institute of Standards and Technology)~~ * ~~`ISO` (International Organization for Standardization)~~ This selection should only permit **one** option to be chosen for now. The proposed workflow is: 1. An `admin` or `group owner` selects `SOX` in `Project A` settings 2. The specific compliance label is rendered on the `project list` as a badge 3. GitLab stores this association to report on in the [Compliance Dashboard](https://gitlab.com/groups/gitlab-org/-/epics/2537) ## Screenshots | Project Settings-BEFORE | Project Settings-AFTER | | ------ | ------ | |  |  | | Project Details-BEFORE | Project Details-AFTER | | ------ | ------ | |  |  | | Projects listing-BEFORE | Projects listing-AFTER | | ------ | ------ | |  |  | <details> <summary>Original proposal</summary> Add a **Compliance Controls** selection capability to the `Group` settings. The MVC selection could be GCF [Change Management 2.01 (CM.2.01)](https://about.gitlab.com/handbook/engineering/security/guidance/CM.2.01_segregation_of_duties.html) for Separation of Duties. Helper text should indicate that GCF CM.2.01 is "aligned with SOC 2 CC8.1 and PCI-DSS 6.4". On the backend, GitLab should attribute specific settings to "compliance" with this control. For example, the following settings being **enabled** are considered "compliant": - [X] Remove all approvals in a merge request when new commits are pushed to its source branch - [X] Prevent approval of merge requests by merge request author - [X] Prevent approval of merge requests by merge request committers If these settings are enabled at the time of a MR approval, the MR widget should show a **positive indicator** (:white_check_mark:) If 1 or more of these settings is disabled, the MR widget should show a **warning indicator** (:warning:) | Group Settings | MR Widget | | ------ | ------ | |  |  | | A settings area to specify the desired Compliance Controls to implement for a `Group`. | | <!-- Selecting this control should add a MR widget notice that reports on the project's MR approvals settings. As demonstrated in https://gitlab.com/gitlab-org/gitlab/issues/34830, we can provide a policy report notice to explicitly confirm: * A MR author was not an approver * Someone with commits in the MR was not an approver * Approvers were not overridden when the MR was created * The test and production environments are separate This setting should be editable only by `Owners` Create a `project template` `Group Owners` can apply to all new `Projects` created in their group. The project template would simply set the appropriate setting(s) to restrict modification of MR approvals at the project-level to only `Owners`. This would both provide consistency with https://gitlab.com/gitlab-org/gitlab/issues/38051, but make compliance, in this particular case, more seamless. Additional or Alternative MVC "starting points": *This suggests a few places to start with an MVC and does not mean we would implement all of the features below as part of this MVC* * Code reviews must pass DAST, SAST, dependency, and license scanning * Vulnerabilities with a Low or Medium impact identified during a merge request should be remediated or accepted with justification * Vulnerabilities with a High or Critical impact identified during a merge request must be remediated * Merge requests that impact critical systems must undergo a Risk Assessment --> </details> ### Links / references