Link violations to framework controls (#12774) · Epics · Epics · GitLab.org

Link violations to framework controls

# Background The compliance violation report can be found in the Compliance centre in GitLab. The purpose of the compliance violation report is to provide a high level view of merge request activity for all projects in a group. Each compliance violation provides a severity, ranging from Info -\> Critical. At the moment, there are only 3 compliance violations that are available, which are: * Author approved merge request * Committers approved merge request; and * Fewer than two approvals Read more [here](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) about the compliance violation report # Problem There are a few key issues with the compliance violation report at the moment, which includes the following: * Compliance violations, as defined in the `Background` above, do not fit a majority of our users use cases at the moment. Feedback via recent customer conversations suggest that there is a lack of understanding about what violations in the compliance centre is actually meant to achieve. In a worst case scenario, it can lead to false 'critical' violations (e.g. see [example](https://gitlab.slack.com/archives/CN7C8029H/p1722274014835829)) that not only confuse users but also has the tendency to create an urgency in the user although the violation may not be 'critical', per se. * From our [Tableau dashboard](https://10az.online.tableau.com/#/site/gitlab/views/PDSecGovernSecurityPolicyMetrics/StandardsAdherenceReportTabClicks/3c49b042-e52f-47a2-aa12-21b80c60b245/1ceef983-f260-4edd-a419-3bad2dc1412e?:iid=1), it is clear that there is a lack of usage of the violation report as it consistently ranks as the feature of the compliance centre that is the least used among all of the other features. Combined together with customer feedback about violations, it shows that it lacks utility with our intended users at the moment (e.g. compliance managers) and improvements need to be made in order to improve it's usage and value with compliance managers today. # Current Assumptions or Pain Points The following are the pain points and benefits of addressing this issue | Pain Point | Benefits | Description | |------------|----------|-------------| | Decreased visibility | Improved visibility | of compliance violations | | Decreased understanding | Improved understanding | of what a compliance violation is in the context of their organizational needs | | Decreased utility | Improved utility | of compliance violations in determining the day to day compliance posture of their projects | | Decreased false positives | Improved 'real' positives | of compliance violations if users were able to define them to track what they considered were violations in the first place | | Misaligned with | Aligns with | 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 | # Possible solution We have a strong hypothesis that users want to be able to link up audit events with violations. This is based off of customer conversations, which indicated that they would like to see violations have a wide variety of use cases which include: * Wanting to be alerted as a violation after any audit events that imply malicious access or information leakage happening for a group or project * Wanting to be alerted as a violation when a maintainer made a change to MR approval rules that * Want to be alerted as a violation when a user makes a change to a framework or a policy without the necessary approvals. However, as can be seen above, there are a wide range of use cases that users have presented as being a potential violation. As such, we want to validate that we are able to cover all of the above uses cases as audit events, or if there are other use cases that we haven't unearthed yet that could point us towards another way in which violations can be utilised in the compliance centre # Persona * [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) ## Next steps * [ ] Could you communicate the idea with both compliance and policy groups? * [ ] Problem validation for compliance * [ ] Problem validation for policies * [ ] Could you clarify the technical possibilities? * [ ] Design explorations for compliance * [ ] Design explorations for policy _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._ _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._  *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