Provide a VEX document

[icekom]

Latest govulncheck versions support outputting OpenVEX formatted documents, which can be submitted to vulnerability scanners to filter out false positives. Right now govulncheck-with-excludes.sh uses the non-standard JSON format and excludes mitigated vulnerabilities. The -json flag is now considered legacy in favor of -format.

Proposal

• govulncheck-with-excludes.sh should be updated to use -format openvex instead of -json and override the status of mitigated vulnerabilities from affected to fixed per OpenVEX spec instead of excluding them.
• ci.yml workflow should provide the resulting VEX document as an artifact.

If that works for you, I can do it and submit a PR.

Caveats

• OpenVEX spec is a draft:

  The OpenVEX specification is currently a draft. We don't anticipate large changes, but are open to them.

  It's already supported by at least Trivy and Grype.

• x/vuln: OpenVEX report lacks affected product golang/go#68152
  Probably solvable with jq in govulncheck-with-excludes.sh

[ajchiarello]

I'd like to support this as well, and also mention VEXHub (https://github.com/aquasecurity/vexhub) - if you provide a VEX attestation and register it with VEXHub, it makes it simple for people using to the Trivy scanner to include your VEX document in their local scans.

[tianon]

I agree, I'd really like to publish some official VEX statements for the project. When I explored this (~2023), the main issue I ran into was that purl is kind of a mess, but is required for a VEX statement to mean anything.

Coming up with a "valid" purl for gosu is easy:

"products": [
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-amd64&checksum=sha256%3Abbc4136d03ab138b1ad66fa4fc051bafc6cc7ffae632b069a53657279a450de3",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-arm64&checksum=sha256%3Ac3805a85d17f4454c23d7059bcb97e1ec1af272b90126e79ed002342de08389b",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-armel&checksum=sha256%3Af9969910fa141140438c998cfa02f603bf213b11afd466dcde8fa940e700945d",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-armhf&checksum=sha256%3Ae5866286277ff2a2159fb9196fea13e0a59d3f1091ea46ddb985160b94b6841b",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-i386&checksum=sha256%3A087dbb8fe479537e64f9c86fa49ff3b41dee1cbd28739a19aaef83dc8186b1ca",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-mips64el&checksum=sha256%3A87140029d792595e660be0015341dfa1c02d1181459ae40df9f093e471d75b70",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-ppc64el&checksum=sha256%3A1891acdcfa70046818ab6ed3c52b9d42fa10fbb7b340eb429c8c7849691dbd76",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-riscv64&checksum=sha256%3A38a6444b57adce135c42d5a3689f616fc7803ddc7a07ff6f946f2ebc67a26ba6",
	"pkg:generic/gosu@1.17?download_url=https%3A%2F%2Fgithub.com%2Ftianon%2Fgosu%2Freleases%2Fdownload%2F1.17%2Fgosu-s390x&checksum=sha256%3A69873bab588192f760547ca1f75b27cfcf106e9f7403fee6fd0600bc914979d0"
],

What's hard is getting scanning tools to actually match this against the binaries they find in the wild, because most of them work by "choosing" a purl for the binary they find (for Go binaries, that's often based on the embedded version data that's frankly almost always wrong, even in 1.24+ where it's willing to embed data from local VCS), so all the gosu binaries in the wild appear as version (devel) which is kind of useless.

To that end, I've played with #155 ("In theory, this will enable us to publish official VEX statements for gosu in a way that scanning tools can actually consume and match correctly."), but it's really hacky and I haven't decided yet if I want to maintain it long-term (especially since Go could easily break it in a new release by not shelling out to git anymore).

[tianon]

It's also really infuriating that vulnerability is a string, not a list, because it means my VEX document needs to be thousands of lines (one "statement" per CVE/identifier) instead of hundreds, but that's not really a blocker, just a huge annoyance (and one that makes it more annoying to decide where to host these files because they're on the order of megabytes instead of kilobytes).

[ajchiarello]

Would vexctl or go-vex help with generating them? It looks like that's what they are designed for.

[tianon]

My original PoC just used jq because they're not terribly complex, just verbose (and the purl blocker). 🤷

[agologan]

While I do agree with the PURL comment, looking at both aquasecurity/vexhub and rancher/vexhub many OpenVex files just do pkg name targeting.
During my own exploration (agologan/vexhub/.../tianon/gosu/scan.openvex.json) also wanting to propose publishing an official OpenVex file, I ended up doing the same for practical reasons.
Even if I could get precise targeting to work with Trivy in my case, I than needed to figure out per version updating and merging into a single document.

I would propose publishing an OpenVex file regardless of precise version targeting to reduce noise coming from existing versions out in the wild. And than followup with more accurate version in an future update.

[grooverdan]

With the fake-git of #155 done (committed now? - provided go remains stable 🤞 ), that that mean the purl becomes 'pkg:golang/github.com/tianon/gosu@v1.19' (or append .0?)?

$ go version -m ./Downloads/gosu-amd64 
./Downloads/gosu-amd64: go1.24.6
	path	github.com/tianon/gosu
	mod	github.com/tianon/gosu	v1.19.0	
	dep	github.com/moby/sys/user	v0.1.0	h1:WmZ93f5Ux6het5iituh9x2zAG7NFY9Aqi49jjE1PaQg=
	dep	golang.org/x/sys	v0.1.0	h1:kunALQeHf1/185U1i0GOB/fy1IPRDDpuoOOqRReG57U=
	build	-buildmode=exe
	build	-compiler=gc
	build	-trimpath=true
	build	DefaultGODEBUG=asynctimerchan=1,gotestjsonbuildtext=1,gotypesalias=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,multipathtcp=0,panicnil=1,randseednop=0,rsa1024min=0,tls10server=1,tls3des=1,tlsmlkem=0,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1,x509rsacrt=0,x509usepolicies=0
	build	CGO_ENABLED=0
	build	GOARCH=amd64
	build	GOOS=linux
	build	GOAMD64=v1
	build	vcs=git
	build	vcs.revision=1.19
	build	vcs.time=1970-01-01T00:00:00Z
	build	vcs.modified=false

With golang/go#68152 as yet unresolved is release generating a version like the following suitable for publishing ?

$ govulncheck -format openvex -mode binary ~/Downloads/gosu-amd64 | jq '(.statements[].products[] | .["@id"]) = "pkg:golang/github.com/tianon/gosu@v1.19" > .vex/gosu-v1.19.vex.json
'
{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "govulncheck/vex:a8d0efc7da3b073486b648b2e66a4b621805af6b1aed5cb9b7b37632c9efd261",
  "author": "Unknown Author",
  "timestamp": "2026-01-05T02:22:56.150170368Z",
  "version": 1,
  "tooling": "https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck",
  "statements": [
    {
      "vulnerability": {
        "@id": "https://pkg.go.dev/vuln/GO-2025-4006",
        "name": "GO-2025-4006",
        "description": "Excessive CPU consumption in ParseAddress in net/mail",
        "aliases": [
          "CVE-2025-61725",
          "CVE-2025-61725"
        ]
      },
      "products": [
        {
          "@id": "pkg:golang/github.com/tianon/gosu@v1.19",
          "subcomponents": [
            {
              "@id": "pkg:golang/stdlib@v1.24.6"
            }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "Govulncheck determined that the vulnerable code isn't called"
    },
....

ref: location at ~9k length

[tianon]

After I merged and released #155, what I found was that many tools still insist that the "vulnerabilities" they find in the gosu binary get attributed to "Go stdlib" at a particular version instead of to gosu, so I kind of lost steam on wanting to publish an official VEX feed somewhere (since the effort wouldn't be rewarded). If there's a tool that does report CVEs in 1.18 or 1.19 and attributes them to this theoretical gosu purl such that a VEX statement could suppress them, and supports VEX statements for suppression, I'll reconsider. 👍❤️😞

[agologan]

Not sure I understand, if you take my example above and remove subcomponent or subcomponent version, Trivy and probably others implementing the OpenVEX standard will correctly suppress vulnerabilities.
With some jq/grep we could get to

    {
      "vulnerability": {
        "@id": "https://pkg.go.dev/vuln/GO-2022-0515",
        "name": "GO-2022-0515",
        "description": "Stack exhaustion due to deeply nested types in go/parser",
        "aliases": [
          "CVE-2022-1962"
        ]
      },
      "products": [
        {
          "@id": "pkg:golang/github.com/tianon/gosu",
          "subcomponents": [{ "@id": "pkg:golang/stdlib" }]
        },
        {
          "@id": "pkg:golang/github.com/tianon/gosu@v1.19",
          "subcomponents": [{ "@id": "pkg:golang/stdlib" }]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "Govulncheck determined that the vulnerable code isn't called"
    },

or more simply

    {
      "vulnerability": {
        "@id": "https://pkg.go.dev/vuln/GO-2022-0515",
        "name": "GO-2022-0515",
        "description": "Stack exhaustion due to deeply nested types in go/parser",
        "aliases": [
          "CVE-2022-1962"
        ]
      },
      "products": [
        { "@id": "pkg:golang/github.com/tianon/gosu" },
        { "@id": "pkg:golang/github.com/tianon/gosu@v1.19" }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "Govulncheck determined that the vulnerable code isn't called"
    },

[tianon]

Creating a VEX is not the problem; that part is trivial, and very well over-solved now (as illustrated above, now even govulncheck itself can create one directly that only needs minor fix-up).

What I need to see in order for me to commit to not only doing that once, but maintaining such a thing over time, is proof that some tool that currently detects CVEs on a gosu binary inside a container image will pick up suppressions correctly, given a gosu-specific purl.

(That's the thing I haven't seen work - the one I tested insists on only matching a generic Go purl for the vulns, without a way to target only gosu.)

[agologan]

Sorry if I wasn't clear, Trivy does detect and suppress the vulnerabilties on a per product basis, assuming it detected some reasonable purl.
Here's a quick snippet I use in my testing

docker volume create trivy
docker run \
  --rm -it \
  -v trivy:/root/.cache \
  -v ./scan.openvex.json:/tmp/scan.openvex.json:ro \
  aquasec/trivy image --vex /tmp/scan.openvex.json --scanners vuln postgres:alpine