Allow empty statements list in schema#64
Open
TimCares wants to merge 2 commits into
Open
Conversation
This change fixes an inconsistency with the OpenVex go client, and also leads to better usability when no CVE has to be triaged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
just a quick PR.
Based on the contributing guidelines (namely Section 4.1) I did not create an issue as this PR is a one liner.
I was recently playing around with the OpenVEX format, and implemented it into my public python development template (commit here).
However, I found that when there are no existing CVEs to triage, and the
statementsfield of the spec is empty, it leads to a json validation error because the spec requires at least onestatementbeing present.Users of this format therefore either have to delete the file, or find some other workaround, as I currently have in my template.
I thought that this was a little cumbersome, as an empty
statementsfields is also quite expressive: “There are (currently) no CVEs to triage in this project.”Therefore, I propose a one line fix:
I am aware of the fact that this might break code of other software/libraries consuming the OpenVex format.
However, from what I saw
trivyseems to be a main consumer of this format, which is why I checked the source code consuming OpenVex:Trivy uses the vex go client, which can be seen in the file
pkg/vex/openvex.go.The go client defines this structure for the OpenVex format:
Link here.
Since this allows an empty
statementslist, there is also a drift between the schema in the go client and the json schema.Using a test run of trivy with OpenVex I verified that trivy can indeed handle an empty
statementsfield:{ "@context": "https://openvex.dev/ns/v0.2.0", "@id": "https://openvex.dev/docs/public/vex-project-template", "author": "Project Maintainers", "timestamp": "2026-06-15T14:13:08Z", "version": 1, "statements": [] }docker run --rm \ -v "path/to/empty/openvex.json:/vex/openvex.json:ro" \ ghcr.io/aquasecurity/trivy:0.70.0 image \ --severity HIGH,CRITICAL \ --vex /vex/openvex.json \ --exit-code 0 \ alpine:3.20The command runs through.
Therefore, I conclude that at least for Trivy, this change/fix can be deemed safe (however, it might not be safe for all consumers).