Unify vulnerability attributes for merge request approval policy
What does this MR do and why?
This change refactors how vulnerability filtering works in a security policy editor. The main improvements include:
Simplified user interface: The KEV (Known Exploited Vulnerabilities) filter now shows a single, clearer message "Only show/block vulnerabilities that are being exploited" instead of having different messages for enabled/disabled states.
Better code organization: The code was restructured to handle vulnerability attributes more consistently. Previously, some vulnerability data was nested under a "vulnerabilities" object, but now it's stored directly at the top level, making the code simpler and more predictable.
Enhanced filtering logic: The system now better separates different types of vulnerability filters (like KEV status and EPSS scores) from basic attributes (like false positives and fix availability), allowing for more flexible combinations of filtering criteria.
Improved data handling: The code now uses more robust methods to merge and manage different vulnerability attributes, ensuring that when users apply multiple filters, they work together correctly without overwriting each other.
These changes make the security policy editor more intuitive for users while making the underlying code more maintainable for developers. The functionality remains the same from a user perspective, but the implementation is now cleaner and more reliable.
References
Screenshots or screen recordings
| Description | UI |
|---|---|
| VUlnerability attributes | kvv.mov |
How to set up and validate locally
-
Enable feature flag:
Feature.enable(:security_policies_kev_filter) -
Go to Secure -> Policies
-
New Merge request policy
-
Select Security scan rule
-
Check new KEV filter
-
Try it with other attribute filter
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #576860