GitHub CI Policy Shift: OpenVEX File Automates 'Won't-Fix' CVE Suppression for High-Severity Vulnerabilities

A proposed change to a GitHub repository's CI/CD pipeline reveals a strategic move to automate the handling of unfixable, high-severity vulnerabilities. The current policy lacks a formal Vulnerability Exploitability eXchange (VEX) register, forcing developers to manually edit workflow scripts each time a permanently unfixable OS-level CVE is identified in security scans. This manual process is a bottleneck and a potential source of error in maintaining a clean security posture.

The proposed solution introduces an OpenVEX document (`.vex/permanent.openvex.json`) directly into the codebase. This file would be natively consumed by major security scanners Grype and Trivy before policy enforcement. Crucially, the system is designed for automation: a post-scan CI step would automatically update this VEX file whenever a scanner flags a new vulnerability with a CVSS score of 7.0 or higher as 'wont-fix' or 'will_not_fix'. This update triggers a pull request for a single human review, after which the suppression becomes self-maintaining, creating a full audit trail for all suppressed findings.

This automation fundamentally changes the vulnerability management workflow. It shifts the operational burden from repetitive manual code edits to a one-time review process for each new, permanent exception. The flow ensures that high-severity vulnerabilities deemed unpatcheable—like the example of a legacy Debian `tar` CVE—are formally documented and suppressed directly within the toolchain, reducing noise in security reports while maintaining accountability through the version-controlled VEX file and scanner `--show-suppressed` flags.