We had this issue filed against Grype earlier today, and it got me thinking about showing information about fixes
Go is treating go-tuf go-tuf/v2 as different packages. But that means go-tuf is an EOL project, and the logical successor is go-tuf/v2. Sure they’re incompatible, but that also happens in every other ecosystem where you can’t just drop in 2.0 when you’re using 1.0
It feels logical to me that you would present the newest version of something as the logical upgrade for whatever you have.
Debian 11 → 12
RHEL 9 → 10
go-tuf → go-tuf/v2
You get the idea.
And in the case of vulnerabilities, the “fixed in” details are really meant to create an actionable outcome. So for example if you’re using version 1.0 of something, and 1.0 is dead, you want to know you can upgrade to 2.0
Based on how vulnerability data works today, the actionable item in the go-tuf case will be “there’s nothing you can do”. But I don’t think that’s really correct. There is something you can do, but it’s going to be painful.
This then brings us to EOL guidance (which we know we would like to do someday). If something is on an EOL list, would it make sense to list some sort of successor? In the case of go-tuf it’s very obvious, but there will be other things that die and have no obvious replacement.
I don’t think this is quite true. Go is making it so that you have to opt-in to cross the major version boundary, because it’s assumed that something will break. But for example if you go to the official Go package listing for v1 you will see a banner that clearly calls out the vulnerability and mentions v2.
Sorry for this aside - the discussion still stands.
I think your question is something like this:
What should Grype display when, in order to fix a CVE, you need to do major work, like upgrade distro or switch across versions with breaking changes between?
I think it’s an important question to think about.
Ideally someday we’ll have a vulnerability dataset that has a list of detailed remediation possibilities for a given vulnerability (in this case we’d be able to note that there is an upgrade path available so it wouldn’t just show up as no fix available), but we can’t represent that in the current v5 schema since fix is just an array of versions. In v6, the fixes ar objects that we can add any additional information we need to.
I’d like to someday get to the point where we can specify the version that fixed a vulnerability along with where to find it, the commit/patch/pr etc that fixed a vulnerability along with where to find it, any other possible in-place remediation (changing configs, disabling features, etc), and something about what the latest known release is so that someone could easilly just skip to the latest release if needed.
Of course, most of these things are probably far in the future, and I’m talking more about annotating the raw vulnerability data rather than how grype chooses to display it once it has the extra data available
Previously, it would have indicated that a fix is available in 2.0.1, and yes, due to the somewhat unintuitive way go does major versions compared to other packaging ecosystems it is a different entry in the go.mod file, but the go tooling also makes this clear when issuing a go get,
go get github.com/theupdateframework/go-tuf@v2.0.1
go: github.com/theupdateframework/go-tuf@v2.0.1: invalid version: go.mod has post-v2 module path "github.com/theupdateframework/go-tuf/v2" at revision v2.0.1
so I think having something was an improvement to having nothing since many people will now just ignore it or never even see it since it appears there is no action that can be taken, but not much we can do about that at this point in time.
I think we might want different user experiences for different things.
For example, if the current distro version doesn’t have a fix, we could try to detect this and print something like
CVE-2021-1234 some-dpkg wont-fix* ....
... snip ...
* Debian 8 is out of support, and CVE-2021-1234 is marked as "wont-fix",
but a fix is available for the same package in Debian 9
For Golang, something like
GHSA-4f8r-qqr9-fq8j go-tuf wont-fx* ...
... snip ...
* `go-tuf` is succeeded by `go-tuf/v2`, which does have a fix...
Does this sort of experience seem good?
There are a few different challenges rolled in here:
How do we detect the information?
What do we recommend to the user?
How do we display the recommendation readably in a terminal table?
and is exactly what we should discuss