spiffe
CVEs in dependencies, support for VEX?
Hello,
I was wondering what's the project's stance on regular security scans for dependencies using tools like trivy. Forgive me if I missed a documentation about it. I was hoping for the next release (1.12.1) to include some bumped dependency versions to get rid of CVEs (for a while) but that is apparently not part of your release process.
Since this is as recurring issue, maybe you would be open to publishing a VEX for CVEs? So far I went with judging and allowlisting CVEs on my own, but it can be hard sometimes for someone who is not the author of the application (and I guess not all users have the dev capabilities to read the code at all). I also imagine it to be more effective to run some scan on your own instead of waiting for users to create issues for each finding.
Looking forward to find out about your view on this!
Hi @tumbl3w33d, thanks for raising this issue. We generally update dependencies through dependabot, reviewing each update to see if any of the CVEs reported for the update affect us in any way.
If we miss anything, we would appreciate being told about it :D. You can either email us, which is the best way if we are actually affected by the CVE, or open an issue.
What dependencies were hoping to be bumped in the latest release?
Hi Sorin,
currently it shows cve-2025-46569 in the open policy agent. It says 1.3.0 is in use and the fix is available with 1.4.0.
There is probably also still cve-2025-302049 but this is already on my ignore list because it is just DoS and I expected it to disappear (due to your dependabot mechanism) over time.
Those are the two high ones. The medium ones (cve-2025-22871, cve-2025-22872) usually aren't that relevant, but there are fixes available for them too.
Edit, display my thousand words in pretty:
Was this for the 1.12.0 images? I think most of those are not in the 1.12.1 images. The only exception is the OPA one, but the advisory for it mentions that it only affects user running OPA as a standalone server, which I don't think is our case.
Go provides an awesome tool for this, govulncheck. I find it's much better than these generic scanners because it actually checks that the code affected by the CVE is reachable from the scanned code.§
We'll discuss some more if we want to run any of these tools in an automated way.
This was a 1.12.0 image that I've built myself. It contains your binaries and trivy reports the CVEs per binary.
It probably makes sense for you to use a more specific scanner, yeah. In my company we scan in all CI pipelines (different tech stacks) on build time and in our harbor registry (which rejects pulls for versions in the field later on).
This CVE issue is omnipresent in all software development and I was pleased to see the info about this VEX standard in the trivy output as possible solution, but I have no experience with it yet. It seems to be an open standard, also supported by other tools.
I'm totally satisfied with your answers. Thank you, feel free to close the issue or keep it open as a reminder for your discussion. :)
I hadn't heard about VEX before reading your issue. Thank you so much for raising it.
I do think VEXes will help solve a major problem with software security.
I wonder how we might maintain them though.
You said you were maintaining them yourself for now. Maybe it is something you could contribute to, and teach us how to maintain them? It seems like an ongoing thing that would need support. Are there any tools you are aware of to help maintain them?
No, what I maintain are just tool-specific lists (one in harbor, one in my CI pipeline that builds my container images and scans with trivy) and there I describe with comments (if possible) why I consider these CVEs irrelevant for our setup. In best case I add a github issue URL that would make these allow-list entries obsolete.
So, I am as hyped as you are, because this approach seems promising in that it would give maintainers of software the chance to get rid of false-positive reports by users and would save the users' time to create those reports. Unfortunately, in this moment I have not much to contribute other than curiosity.
How I would imagine/build it, if I was in your shoes – I would add a vulnerability scan step in some CI workflow and in case there are new findings, I would send out notifications via channels of your choice and then there would be a regular review (i.e. reading what the CVE is about and a quick note in a prepared template about why it is not relevant).
Know if there is a standard yet for making these vex's available? like, can you upload them next to a container image to apply to it?
Know if it is common to make just one vex per software or one per software release? Is it just one that gets updated over time, or multiple where each cve gets its own new one?
trivy's docs answer some of these questions from the consumer's perspective. Looks like there's a multitude of options.
Here is an example of how VEX data following the OpenVEX specification is used by Ubuntu: https://ubuntu.com/security/vex
In addition to the govulncheck already mentioned by @sorindumitru above, there is also:
-
go vet -
semgrep
