BE: Add support for KEV and EPSS filter in MRAP policy

Summary

Add backend support for KEV (Known Exploited Vulnerabilities) and EPSS filtering in Merge Request Approval Policies. This will allow policy creators to define approval rules based on whether a vulnerability has been actively exploited in the wild, enabling more targeted risk-based security policies.

Background

KEV is a boolean indicator (Yes/No) maintained by CISA that identifies CVEs that have been actively exploited in the wild. By incorporating KEV filtering into MR approval policies, AppSec teams can:

  • Prioritize real threats by blocking MRs with vulnerabilities that have confirmed exploitation
  • Reduce false positives by allowing vulnerabilities without known exploitation to proceed
  • Combine with severity levels for sophisticated risk-based policies (e.g., block High severity vulnerabilities only if KEV = true)

KEV data is already available in the pm_cve_enrichment table and is updated regularly. This issue focuses on making that data actionable within MR approval policy evaluation.

Related Work

  • Parent Epic: &16311 (Add filter option for KEV in MR approval policies)
  • Sibling Issue: #577671 (closed) (EPSS filter support - similar implementation pattern)
  • Frontend Issue: [To be created separately]
  • Related: See epic #16311 for feature context

Proposal

Policy YAML Schema Extension

Extend the vulnerability_attributes section to support KEV filtering:

approval_rules:
  - name: Block vulnerabilities with known exploitation
    approvals_required: 2
    user_approvers:
      - security-team-lead
    applies_to_all_protected_branches: true
    security_orchestration_policy:
      type: scan_finding
      branches:
        - main
      scanners:
        - dependency_scanning
        - container_scanning
      vulnerabilities:
        - vulnerability_attributes:
            kev:
              value: true  # Block if KEV = true
            missing_kev_fallback: false  # Optional: default value when KEV data is missing
          actions:
            - type: require_approval

Supported Configurations

  1. Block when KEV = true (most common use case):
vulnerability_attributes:
  kev:
    value: true
    missing_kev_fallback: false
  1. Block when KEV = false (allow only known exploited vulnerabilities):
vulnerability_attributes:
  kev:
    value: false
    missing_kev_fallback: true

Combined Policy Example 

approval_rules:
  - name: Combined severity and KEV policy
    approvals_required: 2
    security_orchestration_policy:
      type: scan_finding
      scanners:
        - dependency_scanning
        - container_scanning
      vulnerabilities:
        - severity:
            - Critical
            - High
          vulnerability_attributes:
            kev:
              value: true
              missing_kev_fallback: false

Implementation Requirements

1. Schema Validation

  • Extend policy schema to accept kev within vulnerability_attributes
  • Validate value field (must be boolean: true or false)
  • Validate optional missing_kev_fallback field (must be boolean: true or false)
  • Add appropriate error messages for invalid configurations
  • Ensure backward compatibility with existing policies

2. Policy Evaluation Logic

  • Implement KEV filtering in MR approval policy evaluation
  • Join security findings with pm_cve_enrichment table using CVE identifiers
  • Extract KEV status for all CVEs associated with a finding
  • When multiple CVEs exist for a single vulnerability: If ANY CVE has KEV = true, treat the entire vulnerability as KEV = true
  • Apply boolean logic to determine policy violations based on kev.value configuration
  • Handle findings without CVEs: exclude from KEV filtering (only applies to DS/CS findings with CVEs)

3. Missing KEV Data Handling

  • When KEV data is missing for a CVE:
    • If missing_kev_fallback is specified in policy: use that value
    • If missing_kev_fallback is NOT specified: treat as false (no known exploitation)
  • Document the default behavior clearly in policy documentation
  • Ensure consistent handling across all policy evaluation paths

4. API Extensions

  • Extend GraphQL/REST APIs to expose KEV status in policy violation responses
  • Include KEV status in security finding details when policy violations occur
  • Ensure APIs return KEV data for MR security reports
  • Add KEV information to existing security dashboard endpoints

5. Bot Comment Updates

  • Update MR approval bot comments to include KEV-related violation details
  • Example: "3 vulnerabilities with known exploitation (KEV) found: CVE-2024-1234, CVE-2024-5678, CVE-2024-9012"
  • Include information about missing KEV data if applicable
  • Add disclaimer about KEV status being snapshot at scan time

6. Performance Optimization

  • Optimize database queries for joining findings with pm_cve_enrichment
  • Add database indexes if needed (coordinate with Database team)
  • Test performance with large vulnerability datasets (100+ findings per MR)
  • Ensure query performance doesn't degrade MR approval checks
  • Consider caching strategies for KEV data lookups

7. Testing

  • Unit tests for KEV filtering logic (both true and false values)
  • Unit tests for multiple CVEs per vulnerability (ANY CVE with KEV = true)
  • Unit tests for missing KEV data handling
  • Integration tests with real policy YAML configurations
  • Integration tests combining KEV with severity filters
  • Edge case tests:
    • Vulnerabilities without CVEs (should be excluded)
    • Invalid CVE formats
    • Empty/null KEV values
    • Mixed KEV status across multiple CVEs
  • Performance tests with high-volume datasets

Technical Implementation Notes

Data Flow 

flowchart TD
  subgraph Database
    pm_cve_enrichment[pm_cve_enrichment Table]
    pm_cve_enrichment --> |contains| cve_column[cve column]
    pm_cve_enrichment --> |contains| kev_column[kev column - boolean]
  end

  subgraph MR_Approval_Process
    mr[Merge Request]
    policy_check[MR Approval Policy Check]
    extract_cve[Extract CVE Identifiers]
    lookup_kev[Lookup KEV Status]
    check_any_kev[Check if ANY CVE has KEV = true]
    apply_fallback[Apply Fallback if Missing]
    evaluate[Evaluate Against Policy Rules]
    decision[Approval Decision]
  end

  mr --> policy_check
  policy_check --> extract_cve
  extract_cve --> lookup_kev
  lookup_kev --> |query| kev_column
  cve_column --> |match with| extract_cve
  kev_column --> check_any_kev
  check_any_kev --> apply_fallback
  apply_fallback --> evaluate
  evaluate --> decision
  decision --> |requires approval?| mr

Key Considerations

  1. Scope: KEV filtering only applies to Dependency Scanning and Container Scanning findings that have associated CVEs
  2. KEV Status Updates: Status is evaluated at scan time (snapshot). If KEV status changes after scan, it won't affect existing MR policy evaluations until pipeline re-runs
  3. No Feature Flag Required: When kev filter is not present in policy YAML, no KEV evaluation occurs
  4. Consistency with EPSS Implementation: Follow similar patterns established in EPSS filter implementation (#577671 (closed))
  5. Boolean Logic: KEV is a simple boolean - either a CVE is in the KEV catalog or it isn't

Edge Cases & Decisions

Scenario Decision
Multiple CVEs per vulnerability If ANY CVE has KEV = true, treat vulnerability as KEV = true
Vulnerability without CVE Exclude from KEV filtering
Missing KEV data in pm_cve_enrichment Use missing_kev_fallback if specified; otherwise treat as false
SAST/Secret Detection findings Not applicable (no CVEs)
Invalid CVE format Treat as missing KEV data
KEV status changes after scan Use snapshot at scan time; re-evaluate on pipeline re-run

Acceptance Criteria

  • Policy YAML schema supports kev filtering with boolean values (true/false)
  • Policy evaluation correctly filters vulnerabilities based on KEV status
  • Multiple CVEs per vulnerability are handled correctly (ANY CVE with KEV = true)
  • Missing KEV data is handled according to defined behavior (default to false)
  • Bot comments clearly communicate KEV-related policy violations
  • APIs expose KEV status in policy violation responses
  • Performance is acceptable for large vulnerability datasets (< 2s for 100+ findings)
  • All tests pass (unit, integration, edge cases, performance)
  • Documentation is updated with KEV filter usage examples

Documentation Requirements

  • Update MR Approval Policy documentation with KEV filter examples
  • Document boolean value behavior (true blocks KEV vulnerabilities, false blocks non-KEV)
  • Document missing_kev_fallback configuration option
  • Document edge cases (multiple CVEs, missing data, non-CVE findings)
  • Add examples of combined severity + KEV policies
  • Document KEV status snapshot behavior (evaluated at scan time)
  • Include link to CISA KEV catalog for reference

Labels

groupsecurity policies Category:Security Policy Management devopssecurity risk management sectionsec security policymerge request approval policy typefeature backend

Weight

TBD - To be estimated by engineering team

Milestone

%18.8

Related Epic:

  • &16311 (KEV filter - parent epic)

Related Issues:

Edited by Imam Hossain