Design violations for controls
Background
The compliance violations report provides users a high-level view of merge request activity for all projects in the group. The compliance violations report can be sorted by severity level (e.g. Info, Low, Medium, High, Critical). There are currently 3 types of violations, which are:
Problem
There are two linked problems with the violations report:
- Users are unaware or just not sure exactly what violations mean, either in the context of their day to day workflow or in the GitLab, as it is unclear what relationship it might share to failed checks/controls in GitLab at the moment;
- There is no obvious inherent link between a check/control in GitLab today with a violation, which further decreases the utility of a violation for our users; and
- As a result, the compliance violations report has the lowest engagement by our users (e.g. number of clicks, views etc.), which is something that we want to improve moving forward
Current Assumptions and Pain Points
The following are the pain points and benefits of addressing this issue:
| Pain Point | Benefit | Description |
|---|---|---|
| Decreases understanding | Improves understanding | of what 'violations' mean in the GitLab context and how it can help users achieve adherence to a particular compliance framework |
| Decreases engagement | Improves engagement | of the compliance violation report, as users will now understand what violations mean and how it can help them achieve adherence to a particular compliance framework |
| Decreases visibility | Improves visibility | over any failed controls that were due to a lack of setting or policy being enforced on that control due to a violation being flagged by an audit event |
| Decreases user satisfaction | Improves user satisfaction | due to being able to make use of the compliance violations report on a day to day basis as another 'tool' in the compliance toolbox to monitor compliance for all projects in a particular group |
| Misaligned with | Aligns with | the direction of the Compliance group, to achieve compliance visibility of checks, violations and audit events throughout the entire DevSecOps lifecycle |
Proposed Solution
Moving forward, we have defined the goal of violations as being related to any action or event that triggers the non-compliance of a GitLab instance.
In order to achieve this goal, there are 2 core aspects to our proposed solution:
- We want to link up checks/controls to certain audit events, as a way to track the 'who' and 'what' when it comes to a failed check or control; and
- When the audit event is triggered, it will signify that a certain action conducted by a certain user has caused the check or control to fail, which will also be highlighted in the compliance violation report.
For example:
- Requirement: Two person approvers
- Check: Review projects MR approval settings.
- Policy: Merge request approval policy using the approvals_required param to ensure 2 approvals
- Violation: Two audit event types selected - (Merge request merged with one approver, Merge request merged with no approver)
Personas
JTBD User Stories
| Issue | Persona | User Story |
|---|---|---|
| User wants to understand what compliance 'violations' have occurred for GitLab projects within a group | Cameron (Compliance Manager) |
When I am viewing the compliance violation report; I want to understand, at a glance, what compliance violations are occurring across all of the projects in my group; So I can understand whether there are any projects that have a failing check/control or existing violation |
| Users want to understand whether a compliance violation has resulted due to a failed check/control | Cameron (Compliance Manager) |
When I am viewing the compliance violation report; I want to understand which checks/controls have failed due to an audit event being recorded, which kicked off a violation; So I can understand the type of compliance violation that occurred |
| Users want to set a severity level to a compliance violation | Cameron (Compliance Manager) |
When I am creating a framework with the associated checks/controls; I want to be able to specify how severe a violation of a failed check/control is; So I can understand whether or not the violation needs to be resolved immediately. |
| Users want to be guided to resolve a violation in order to fix a failed check/control | Cameron (Compliance Manager |
When I am trying to resolve a compliance violation; I want to be provided guidance and documentation from identification of the violation to it's eventual resolution; So I can fix any failed checks/controls that was related to the violation in the first place. |
Design
Please see design section for details