# Discussion about vulnerability fixed information **URL:** \ **Category:** Grype\ **Tags:** discuss\ **Created:** [October 10, 2024, 4:22pm UTC](https://anchorecommunity.discourse.group/t/discussion-about-vulnerability-fixed-information/172 "2024-10-10T16:22:43Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![joshbressers](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/joshbressers/32/19_2.png) [@joshbressers](https://anchorecommunity.discourse.group/u/joshbressers)\ **Post date:** [October 10, 2024, 4:22pm UTC](https://anchorecommunity.discourse.group/t/discussion-about-vulnerability-fixed-information/172/1 "2024-10-10T16:22:43Z")
We had this issue filed against Grype earlier today, and it got me thinking about showing information about fixes > > > \*\*What happened\*\*: > Grype looks to be falsely reporting that images are affected… by GHSA-4f8r-qqr9-fq8j, by not considering there are two different packages with similar names. One is a 'v2' package with differnt versioning, the other is not. > > \*\*What you expected to happen\*\*: > > I'd expect grype to be aware, that GHSA-4f8r-qqr9-fq8j affects 'go-tuf/v2', and NOT report any related findings, when scanning packages that contain 'go-tuf' - i.e the non-v2 version: > > \- https://pkg.go.dev/github.com/theupdateframework/go-tuf > \- https://pkg.go.dev/github.com/theupdateframework/go-tuf/v2 > > \*\*How to reproduce it (as minimally and precisely as possible)\*\*: > > Scan any image that contains the non-v2 version of go-tuf dependency. Here is one such example: > > \`\`\`bash > grype cgr.dev/chainguard/zot:latest > ... > ... > NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY > github.com/theupdateframework/go-tuf v0.7.0 2.0.1 go-module GHSA-4f8r-qqr9-fq8j High > \`\`\` > > We can see that its correctly detected 'github.com/theupdateframework/go-tuf' and its the v1 version, and v0.7.0 is installed. This lines up with the latest version available here: https://pkg.go.dev/github.com/theupdateframework/go-tuf > > But we are incorrectly saying its fixed in v2.0.1, which is not the case, as GHSA-4f8r-qqr9-fq8j relates to go-tuf/v2 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. ---
**Author:** ![willmurphy](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/willmurphy/32/12_2.png) [@willmurphy](https://anchorecommunity.discourse.group/u/willmurphy)\ **Post date:** [October 10, 2024, 4:27pm UTC](https://anchorecommunity.discourse.group/t/discussion-about-vulnerability-fixed-information/172/2 "2024-10-10T16:27:53Z")
> [@joshbressers](#): > > Go is treating go-tuf go-tuf/v2 as different packages. 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](https://pkg.go.dev/github.com/theupdateframework/go-tuf) you will see a banner that clearly calls out the vulnerability and mentions v2. ![screenshot of go-tuf on pkg.go.dev](https://global.discourse-cdn.com/free1/uploads/anchorecommunity/original/1X/bc144430ebc12c6d6a785a38ccba18c2463c5b57.png) 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. ---
**Author:** ![joshbressers](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/joshbressers/32/19_2.png) [@joshbressers](https://anchorecommunity.discourse.group/u/joshbressers)\ **Post date:** [October 10, 2024, 4:29pm UTC](https://anchorecommunity.discourse.group/t/discussion-about-vulnerability-fixed-information/172/3 "2024-10-10T16:29:54Z")
@willmurphy I think your question is what my very long explanation failed to ask 🙂 and is exactly what we should discuss ---
**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\ **Post date:** [October 11, 2024, 9:41am UTC](https://anchorecommunity.discourse.group/t/discussion-about-vulnerability-fixed-information/172/4 "2024-10-11T09:41:10Z")
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 ---
**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\ **Post date:** [October 11, 2024, 9:57am UTC](https://anchorecommunity.discourse.group/t/discussion-about-vulnerability-fixed-information/172/5 "2024-10-11T09:57:36Z")
I do rather dislike that current grype is no longer going to show that there is a possible remediation path available for CVE-2024-47534 for someone using `github.com/theupdateframework/go-tuf` now that [[GHSA-4f8r-qqr9-fq8j] Incorrect delegation lookups can make go-tuf download the wrong artifact by mamccorm · Pull Request #4893 · github/advisory-database · GitHub](https://github.com/github/advisory-database/pull/4893) has been merged, but I also don’t think there is anything that can be done with the current grype db v5 schema and our existing data processes (apart from maintaining our own fork of the advisory database which we do not have the capacity for currently) to address it 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, ```sh 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. ---
**Author:** ![willmurphy](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/willmurphy/32/12_2.png) [@willmurphy](https://anchorecommunity.discourse.group/u/willmurphy)\ **Post date:** [October 11, 2024, 12:17pm UTC](https://anchorecommunity.discourse.group/t/discussion-about-vulnerability-fixed-information/172/6 "2024-10-11T12:17:00Z")
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 ```auto 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 ```auto 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: 1. How do we detect the information? 2. What do we recommend to the user? 3. How do we display the recommendation readably in a terminal table?