Enhance Merge Request Approval Policies to support individual scanner instances within the same scanner type
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Problem to solve
Currently, GitLab's merge request approval policies only allow gating on security scan result types (container_scanning, secret_detection, sast, etc.) without the ability to differentiate between multiple scanner instances of the same type.
Some organizations are implementing custom security scanners using the GitLab security scanner integration framework. They want to run their custom scanners alongside GitLab's native scanners of the same type (e.g., custom container scanner + GitLab container scanner), but need the ability to enforce different approval requirements based on which scanner found the vulnerabilities.
Use case
A financial services organization is implementing an additional container scanner that runs alongside GitLab's native container scanning. They want to create approval policies that only block on vulnerabilities found by their custom scanner, not those found by GitLab's scanner.
For example:
- Scanner A (GitLab native container scanner) finds vulnerabilities that are advisory only
- Scanner B (Organization's custom container scanner) finds vulnerabilities that should block merges
Currently, the approval policies can only apply to all "container_scanning" results, not specifically to Scanner A or Scanner B.
Proposal
Enhance the merge request approval policy schema to support specifying individual scanner instances within a scan type. The enhanced policy could extend the existing "scanners" field in the approval policy to allow specifying both the scanner type and the scanner name/ID.