[TimCares]

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 statements field of the spec is empty, it leads to a json validation error because the spec requires at least one statement being 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 statements fields is also quite expressive: “There are (currently) no CVEs to triage in this project.”

Therefore, I propose a one line fix:

- “minItems": 1,
+ “minItems": 0,

---

I am aware of the fact that this might break code of other software/libraries consuming the OpenVex format.
However, from what I saw trivy seems 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:

// The VEX type represents a VEX document and all of its contained information.
type VEX struct {
	Metadata
	Statements []Statement `json:"statements"`
}

Link here.

Since this allows an empty statements list, 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 statements field:

{
  "@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.20

The 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).

[puerco]

@TimCares this PR makes sense to me. So far it has not surfaced as ready to merge because it is failing the DCO check, can you amend the commit with a signoff? And then we can merge this for the pre-v1 release.

[miniprow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: TimCares
Once this PR has been reviewed and has the lgtm label, a repository administrator can /approve this pull request. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from a repository administrator.

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment