Add MR Report Compliance Approvals in Merge Requests
Problem to solve
Compliance departments want to ensure that certain rules are followed. The intent behind this is to build a special rule within the Merge Request that looks for results from specific Report Artifacts and determines whether or not those artifacts validate compliance or lack thereof.
If the compliance rules are met (a set of specified artifacts:reports have been generated for a given pipeline), then the MR can proceed without needing the MR to be approved by a designated Compliance Team member.
If the compliance rules are not met, then the MR can only proceed after the MR is approved by a designated Compliance Team member.
Intended users
User experience goal
The intent is to loop compliance teams into the MR process when specific compliance rules (aka artifacts:reports) are not being created. For example, ensuring that SAST scans are being run.
Proposal
Similar to the Vulnerability-Check (docs), this aims to provide users the ability to define a Compliance-Check MR Approval Rule that, when created, checks for specific results in the Pipeline Reports Artifacts.
Setting Up The Rule
The rule will initially be defined in the MR Approvals section. The Compliance-Check approval rule name is a keyword that GitLab will use to intelligently determine special rules need to be applied, following the same experience as the Vulnerability-Check approval rule name.
MR Page When Security Scanning Jobs Detect Vulnerabilities & Compliance Jobs Detect Compliance Issues
When implemented, the MR will dynamically look for specific artifacts:reports. To begin with this might be a statically defined list of artifacts (for example artifacts:reports:sast, artifacts:reports:codequality, artifacts:reports:license_scanning) but could later be user-defined. Based on the output of these reports will either allow the MR to proceed without approval from the Compliance Team because the checks succeeded or require approval because the compliance checks failed.
MR Page When Security Scanning Jobs Do NOT Detect Vulnerabilities & Compliance Jobs Do NOT Detect Compliance Issues
Notice how the screenshot above requires Compliance-Check approval 0 of 1 whereas the job below lists them as (optional). This is because the most recent pipeline successfully generated all of the necessary and agreed upon artifacts:reports.
Further details
This, in addition to a Code Owners File requiring the Compliance Team to verify any changes to the CI YAML could help ensure that the Compliance Team is engaged any time a specific Compliance Job is modified/removed/etc...
In the future, this idea can be built upon to include specific results expectations for the artifacts:reports including their job state (succeed/fail) as well as results. An example would be the code coverage job may be specified so that it needs to complete successfully and be above a certain percentage in order to not require sign-off from compliance.
The Vulnerability-Scan MR Approval Rule currently has static criteria. An issue exists (#216593 (closed)) to expand upon this to support dynamic rulesets. It ought to be assumed that their UX should align to future iterations on the Compliance UX. Their current "intelligent ruleset" is as follows:
A merge request approval is required when a security report contains a new vulnerability of high, critical, or unknown severity.