Add the Inspektor Gadget repository

[burak-ok]

Hello,

Thanks for providing a mechanism to respond to CVEs in dependencies that are not affecting a project.
With this PR we want to add the Inspektor Gadget vex files to the official vex hub.

[CLAassistant]

All committers have signed the CLA.

[knqyf263]

Thanks for your contribution! The test is failing, but it seems to be an error unrelated to your changes. Please wait a moment while we fix it.

Oops: failed to crawl packages: strict: failed to crawl package: failed to walk the directory: failed to walk the directory: lstat /tmp/vexhub-crawler-416422651/webhook/pkg/golang/github.com/harvester/webhook: no such file or directory
Code: crawl_package
Time: 2025-10-27 05:57:23.371101294 +0000 UTC
Domain: crawl
Trace: 01K8J3WAK8YENCZSNWGJEGK1Y6
Context:
  * url: {https://github.com/rancher/vexhub 1 main pkg/golang/github.com/harvester/webhook}
  * type: golang
  * purl: pkg:golang/github.com/harvester/webhook
  * dir: vexhub/pkg/golang/github.com/harvester/webhook

[knqyf263]

I'm checking with Rancher.
#31

[knqyf263]

@burak-ok Do you mind rebasing/merging the main branch?

[knqyf263]

Is inspector-gadget written in C? If so, since our scanner Trivy does not support binaries built in C, this VEX file cannot be used.

VEX registration itself is fine because VEX Hub does not exist solely for Trivy, but it is primarily intended for automatic VEX discovery by scanners, so we probably need to first organize the use cases of inspector-gadget’s VEX.

Let’s look at a concrete use case using Rancher as an example. A scanner can obtain information such as the root module name of a binary built with Golang from the ELF header and other metadata. In other words, by analyzing the binary, it can retrieve information like github.com/rancher/rancher@2.9.8. Next, it searches the VEX Hub, and if a matching VEX is found, it automatically uses that VEX.

[burak-ok]

Is inspector-gadget written in C? If so, since our scanner Trivy does not support binaries built in C, this VEX file cannot be used.

Inspektor Gadget is written in Golang - The C files are some linux header files

VEX registration itself is fine because VEX Hub does not exist solely for Trivy, but it is primarily intended for automatic VEX discovery by scanners, so we probably need to first organize the use cases of inspector-gadget’s VEX.

That is what we want. For example we got flagged for CVE-2025-54388 and then put it in the vex document in https://github.com/inspektor-gadget/inspektor-gadget/blob/main/.vex/v0.41.0.vex.json and https://github.com/inspektor-gadget/inspektor-gadget/blob/main/.vex/v0.42.0.vex.json

Looking at our vex files we used "@id": "pkg:github/inspektor-gadget/inspektor-gadget@v0.42.0", whereas deducing from your example it should be "@id": "pkg:golang/github.com/inspektor-gadget/inspektor-gadget@v0.42.0".

Is this assumption correct?

[knqyf263]

Looking at our vex files we used "@id": "pkg:github/inspektor-gadget/inspektor-gadget@v0.42.0", whereas deducing from your example it should be "@id": "pkg:golang/github.com/inspektor-gadget/inspektor-gadget@v0.42.0".

Yes, it's correct. For example, even if Node.js package A and Python package A share the same name, they are completely different entities, so the appropriate vulnerability advisory is identified based on the ecosystem. If it is written in Go, setting the PURL type to "golang" will allow the VEX document to be correctly located.