Internal custom controls (#14024) · Epics · GitLab.org

Internal custom controls

## Background & Problem Please read this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/451414 "Custom check technical exploration") Currently all standards adherence report checks are manually created and use instance/group or project settings https://docs.gitlab.com/ee/user/compliance/compliance_center/#compliance-standards-adherence-dashboard This can impact users that are looking for slight variations or complete new standards checks. For example the GitLab standard current has a check to ensure that MRs have at least two approvals. https://docs.gitlab.com/ee/user/compliance/compliance_center/#gitlab-standard, but users may only require 1 approver. ## Current Pain Points <table> <tr> <th>Pain Point</th> <th>Benefit</th> <th>Description</th> </tr> <tr> <td>Decreased flexibility</td> <td>Improved flexibility</td> <td> with the number of project settings that can be applied as a check as they have a number of different requirements which can't be hardcoded for them all the time. </td> </tr> <tr> <td>Decreased usability</td> <td>Improved usability</td> <td>to apply checks outside of formal legal frameworks to reflect internal company policies, which are based off of the project settings in a GitLab project so that they can have an additional level of compliance.</td> </tr> <tr> <td>Decreased usability</td> <td>Improved usability</td> <td>of checks that can be customized according to the needs of the company, rather than just relying on hardcoded checks in GitLab.</td> </tr> <tr> <td>Misaligned with</td> <td>Aligns with</td> <td> the [direction of the Compliance group](https://about.gitlab.com/direction/govern/compliance/), to achieve compliance **visibility** of **checks**, **violations** and **audit events** throughout the entire DevSecOps lifecycle </td> </tr> </table> ## Proposed Solution We could create our own UI engine to create custom checks. Similar to the [Policy Editor](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor), we could create a Checks editor UI, which can do the following: - Users would create a new Check, then add one or multiple conditions. - Each condition would consist of selecting from a list of settings/attributes, selecting an operator (=, !=, matches, etc) and then enter a value. - Each condition could also be AND or OR. This way users could chain together logic using defined settings/attributes and customise as much as they want. (NOTE: This would be significantly more effort then the above option, and probably a future iteration.) ## Assumptions to Validate | Assumption | T/F/N | Why? | |------------|-------|------| | Users want to be able to create customizable checks within GitLab | | | | Users are comfortable managing 10-40 requirements per standard, and 1-3 checks per requirement | | | | Users want to primarily do this via the UI, rather than via YAML or code first approach | True | | | Users want to combine a number of different settings together (\> than 2) to create a customizable check | | | | Users want to have access to the full breadth of settings in CI/CD, Repository and MR to create customizable checks | | | | User wants to check the state of a project using custom logic and something that is not in the Check library | | | | Users attribute project settings as conditions for checks, and nothing else | | | | Users would like to exclude, include or optionally include certain settings as part of their customizable check | | |  *This 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.*

epic