#3682·grype

OpenVEX transformer drops Go module namespaces from package handles

Author: noqtCreated Aug 30, 2026Updated Aug 30, 2026

What happened:

The v6 OpenVEX transformer drops the namespace from Go module PURLs. On current main (f6f2ce0a2293e65c97bf5468926cb0c9ddad822f), packageNameFromPURL only reconstructs namespaces for Maven and npm, so:

pkg:golang/github.com/gin-gonic/[email protected] -> gin

The GHSA transformer and Go matchers use github.com/gin-gonic/gin. That leaves the OpenVEX package handle on a different packages row, so a statement for the module can be missed.

What you expected to happen:

Go PURLs should retain the full module path: github.com/gin-gonic/gin. The mapping should stay ecosystem-aware; joining every namespace would incorrectly turn pkg:rpm/redhat/openssl into redhat/openssl.

How to reproduce it (as minimally and precisely as possible):

Add this focused case beside the OpenVEX transformer tests:

go
p, err := packageurl.FromString("pkg:golang/github.com/gin-gonic/[email protected]")
if err != nil {
    t.Fatal(err)
}
if got := packageNameFromPURL(&p); got != "github.com/gin-gonic/gin" {
    t.Fatalf("packageNameFromPURL() = %q, want %q", got, "github.com/gin-gonic/gin")
}

Then run:

bash
go test ./grype/db/v6/build/transformers/openvex

The assertion reports got "gin".

Anything else we need to know?:

This surfaced while reviewing #3654. I’m reporting it separately so that narrow DB-search fix can land unchanged. A focused Go regression should come first; after that, either extend the build-side switch or share the mapping if that does not create an awkward dependency boundary.

Reported from NOQT.

Environment:

  • Output of grype version: source at main commit f6f2ce0a2293e65c97bf5468926cb0c9ddad822f
  • OS: Windows reviewer host; Go 1.26.3