Design: Filter options for KEV/EPSS

Problem and scope

See details

What is the problem to solve?

GitLab's merge request approval policies only support filtering vulnerabilities by license severity or vulnerability severity. AppSec teams need more granular control over which security findings should block merge requests based on Known Exploited Vulnerabilities (KEV) and Exploit Prediction Scoring System (EPSS) data. This limits their ability to prioritize the most critical security risks that have actual exploitation potential beyond just CVSS-based severity scoring.

Who is the design solution for?

  • Application Security Engineers and Security Team Leads
  • DevOps Engineers and Engineering Managers

What is the Job this user is trying to achieve?

  • Enable AppSec teams to create more intelligent, risk-based security policies that automatically block merge requests containing vulnerabilities that are known to be exploited in the wild or have high probability of exploitation, while reducing false positives from theoretical vulnerabilities.
  • ...

What outcomes is this design solution helping them achieve?

If you have measured Outcome data, put that in the table. If not, delete the table and add the Outcomes to be designed for in a bulleted list.

  • Reduce time spent manually reviewing MR security findings by filtering for only high-risk vulnerabilities
  • Increase confidence that blocked vulnerabilities represent actual security risks
  • Minimize development workflow disruption from low-risk vulnerability alerts

What are the requirements necessary to solve for this problem and Outcomes?

{ Create a bulleted list of everything that will need to be addressed in the holistic Design Vision in order to fully solve for the problem and Outcomes. Work with your counterparts to define this list. Keep it solution agnostic and try to understand any technical constraints that each requirement may imply. Only remove a requirement due to a technical constraint if it's not technically feasible to build within a reasonable amount of time (1-3 milestones is reasonable, anything longer than that you'll have to decide as a team how important it is to keep it in scope or address it in parallel in later iterations). }

  • KEV Status Filtering: Enable policies to block/allow based on whether a vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog
  • EPSS Score Thresholds: Support filtering based on EPSS scores (0-1 scale) with configurable operators (greater than, less than, between)
  • Scanner Type Support: Initially support Dependency Scanning and Container Scanning findings that have CVE identifiers
  • Policy Evaluation Logic: Extend existing vulnerability filtering to process KEV/EPSS criteria alongside current severity-based rules
  • Clear Feedback: Provide detailed policy violation messages showing why an MR was blocked (e.g., "3 vulnerabilities with EPSS > 0.8 found")
  • Performance Optimization: Ensure policy evaluation remains performant with large vulnerability datasets
  • Edge Case Handling: Define behavior for vulnerabilities without CVE identifiers or missing KEV/EPSS data

What supporting research or customer validation do we have?

  • Competitive Analysis: Snyk offers similar risk-based filtering with "known exploits" categories and ignore policies
  • Customer Pain Points: Current severity-based filtering creates too many false positives, requiring manual review
  • Technical Validation: KEV and EPSS data already exists in GitLab's p_cve_enrichment database table

What is the timeline?

{ Add milestone or link to planning issue that clarifies when the design must be ready for the Build phase by }

What are the technical constraints?

{ ⚠️ This is to understand initial constraints in which the design solution needs to work within, NOT whether the solution can be implemented in a given milestone.

Once the Product Designer has come up with a holistic Design Vision, or an ideal state for solving the problem, they should collaborate with their team members and engineers to continue the technical feasibility discussion during workflowplanning breakdown. }

  • { e.g. All visualization must use [eCharts](https://echarts.apache.org/examples/en/index.html#chart-type-line) }
  • { e.g. Data prior to 2024-10-10 will not be available }
  • { e.g. Solution will only be visible to Maintainer roles }

In what parts of GitLab will this solution be available?

Plans:

  • Free
  • Premium
  • Ultimate

Instances:

  • Self-managed
  • Dedicated
  • GitLab.com

Levels:

  • Instance
  • Group
  • Project

How will we know if the solution is successful?

{ If you don't have measured Outcome data to measure against, what other success metrics can we use? Otherwise you can reference the Outcomes table above (your goal is to beat the previous Outcome measurements Satisfaction numbers with this new design). }

Ready for design

See checklist
  • The problem has been defined and is well understood
  • Who the design solution is for has been defined
  • User goals and outcomes have been defined
  • Supporting research has been reviewed and linked
  • The product requirements have been defined, and the scope has been agreed upon
  • Success metrics have been defined and agreed upon
  • I, as the Product Designer, believe I have all the information I need to begin creating a design solution
  • Move this issue to ~"workflow::ready for design" or workflowdesign 🎉
  • (Optional) Help improve this issue template, view feedback issue

Proposal

See checklist reminder

Design breakdown

Once the proposal is agreed upon, work with your team to break it down into buildable parts (MVC, Iteration 1, Iteration 2, etc... until fully built).

See checklist
  • Design Vision broken down into MVC and follow-up iterations based on their ability to stand alone and provide value to the user
  • Create MVC and other necessary Iteration 1, Iteration 2... issues and add them as Linked items to this issue
    • Include all necessary requirements, and specs needed to create the designs for each broken down issue
Edited by Torian Parker