Display security policy violation details in bot comment
Release notes
Problem to solve
As a security or compliance professional (and as a developer), I want to understand which policies were violated in an MR, and what led to the violation. Violations of a policy enforced by a scan result policy result in blocking merge requests and requiring approval from designated approvers.
Security and development teams must collaborate when an MR is blocked to remediate issues or determine if there are unrelated issues causing the MR to be blocked. A few scenarios may occur:
- Vulnerabilities introduced in the MR violate the policy rules, such as a Critical SAST finding violates a policy that blocks MRs when Critical SAST findings are detected. In this case, the MR widget should likely display the offending vulnerability as well, which makes it straightforward enough for the team to identify today. However, other scenarios are not as straightforward.
- A vulnerability detected by Dependency Scanning may violate a policy. The vulnerability may exist on the default branch and a new CVE has triggered the finding as a new violation. While other efforts will likely address this gap, details about this violation in the MR would give users insight to take action.
- An error may occur in the configuration, such as a mismatch between the scans between source and target branch, which are required for a valid comparison.
- Invalid approvers may lead to an MR being blocked, requiring the issue to be addressed before MRs can be merged. While there are details provided in the MR widget for this scenario, we don't consistently provide details about violations more broadly.
- If a parent/child pipeline is used to execute scans, our approval logic does not properly handle this case. Any known cases that may lead to conflicts or errors can be handled and communicated through this bot comment.
- Perhaps multiple vulnerabilities that violate policies are detected. Providing a clean/clear list of the offending vulnerabilities will reduce any confusion and prevent users from potentially addressing one vulnerability and rerunning the pipeline to learn it's still blocked.
Intended users
User experience goal
Proposal
1. Create a robust API that we can leverage to handle violation details generically
By focusing on the API solution first as an MVC, we can ensure the data we need is captured and we can iterate to identify the ideal UI patterns for displaying the data.
A generic solution will allow us to also display the data in other interfaces, such as the WebIDE and VS Code extension. Other teams would also be undeterred in leveraging the API to build this independently.
2. Once we have the API, we can work to display this additional content in the bot comment as an MVC step
We could display content in the comment to cover Violations and Errors:
Violations
- Line 34 -- /Filepath/Filename.md -- Critical SAST Vulnerability
- Line 325 -- /Filepath/Filename.md -- High Dependency Scanning Vulnerability
Errors
- //verbose error message
3. Expand to create more custom workflows
In future iterations, we could explore new UI interactions for exposing violation data in the MR Widget, MR Details, and as discussed in Surface security policy violations details (Dif... (&10975), in the MR diff view.
Further details
- In Surface security policy violations details (Dif... (&10975), the epic considers vulnerabilities violating a policy, there are further scenarios not considered. It would only capture a subset of the cases that may cause an MR to be blocked.
- This epic will be focused on providing more general violation details and error messaging in the MR, allowing users to troubleshoot and take action to unblock the MR.