Support VEX Input for Trivy Scans
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Help teams focus on resolving exploitable vulnerabilities by incorporating Vulnerability Exploitability Exchange (VEX) documents into security scans.
Problem to solve
As more vendors are publishing VEX attestations for their products, and more scanning tools (like Trivy) are supporting VEX inputs. (Reference: https://trivy.dev/v0.65/docs/supply-chain/vex/ ). These attestation documents can help with remediation workload by providing an "exploitability" status, notes, justification, etc for specific vulnerabilities. This exploitability information could be used in many points within GitLab's security features, however, there is currently no easy way to pass these VEX inputs through to the Trivy utility.
Proposal
Add a support for trivy's new --vex argument, potentially via one or more new CS_ variables. This would provide provide initial configuration option for users of the container_scanning job to pass in local file paths. Trivy also has a --show-suppressed argument which will also output any vulnerabilities suppressed by the VEX statements, along with the relevant status, statement, and VEX source.
At the very least, this would allow non-exploitable vulnerabilities to not be reported, but it also sets up possibility for future enhancements in the security/vulnerabilities report.
Intended users
Personas are described at https://handbook.gitlab.com/handbook/product/personas/