chore: add VEX document and generator for Trivy

[knqyf263]

Overview

This PR introduces an OpenVEX generator for Trivy. This tool generates OpenVEX with govulnchedk to reduce false positives in vulnerability scanning by explicitly declaring "not_affected" statements for vulnerabilities that do not impact Trivy.

Key Features

• Generates OpenVEX documents for Trivy versions v0.40.0 and later and combine them
• Focuses solely on "not_affected" statements to address false positives, not "fixed" and "affected"
• Optimizes VEX representation by omitting version information for vulnerabilities that are "not_affected" across all versions

I chose v0.40.0, not for any particular reason, but because it is old enough that I thought many users would be using a newer version than that.

Implementation Details

1. The script clones or updates the Trivy repository
2. It retrieves and processes tags (versions) starting from v0.40.0
3. For each tag, it runs govulncheck to generate VEX documents
4. The generated VEX documents are then combined and optimized

Addressing govulncheck Limitations

The current version of govulncheck (v1.1.2) has some limitations:

• Products are marked as "unknown"
• Subcomponents are marked as "unknown"
• All statuses are set to "not_affected"

To overcome these issues, our script:

• Fills in the correct product information by our script
• Uses the JSON format (govulncheck -format json) in conjunction with OpenVEX to gather additional data, such as subcomponents
• Determines the actual "not_affected" status by combining information from both formats

This will improve as more features are added to govulncheck.

Optimization Strategy

While it's possible for a vulnerability to be "affected" in one version and "not_affected" in another, let's say Trivy v0.50.0 uses a vulnerable function, Solver.Solve in moby/buildkit, but stop using the function in v0.51.0, I assume this is relatively rare. Therefore, for vulnerabilities that are "not_affected" and "fixed" across all versions from v0.40.0 onwards, we declare them as "not_affected" for all Trivy versions by omitting the version in the product PURL. The product ID would be pkg:golang/github.com/aquasecurity/trivy rather than `pkg:golang/github.com/aquasecurity/trivy@0.53.0.

Please refer to the committed OpenVEX file in this PR for concrete examples of the generated output.

Next Steps

• Automate the process with GitHub Actions
• Consider expanding coverage to versions prior to v0.40.0 if deemed necessary

Checklist

• [x] I've read the guidelines for contributing to this repository.
• [x] I've followed the conventions in the PR title.
• [ ] I've added tests that prove my fix is effective or that my feature works.
• [ ] I've updated the documentation with the relevant information (if needed).
• [ ] I've added usage information (if the PR introduces new options)
• [ ] I've included a "before" and "after" example to the description (if the PR is a user interface change).

[nikpivkin]

Why is the file vex.go in misc and not in magefiles?

[knqyf263]

Why is the file vex.go in misc and not in magefiles?

Yeah, it's better to put it in magefiles. I didn't mean to commit this file at the beginning, and I found some issues in govuncheck. After all, the script is not small anymore and I committed it. I didn't carefully think about the script. I'll move it.

[knqyf263]

Why is the file vex.go in misc and not in magefiles?

Moved https://github.com/aquasecurity/trivy/pull/7128/commits/527b03318e944addec4ede6fb95f4ab0edf74627