-
Notifications
You must be signed in to change notification settings - Fork 574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: use Go main module version when possible #1797
Conversation
When its helpful, that is. This doesnt change the behavior of matching a main module with "(devel") as the version, but in cases where a more useful version is provided, such as when Syft was able to compute a reasonable pseudoversion, we use the version in for best effort matching. Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Good news! I cannot find an increase in FP that this PR introduces from a first glance. @luhring Is there a case you saw where a new FP was introduced by this change? I can confirm that the FN example you provided does work and is now showing up in results. |
No actually, good question. My reason for expecting them is that I can dream up edge cases, like when the GHSA fixed version is |
I did a bit more digging here to find an FP that would get surfaced by this change. Something like this:
Now reports:
Here grype now surfaces I still agree with this change in so much that grype should not be assuming the data coming from the SBOM for go versions are incorrect or incomplete and discounting pseudo versions from matching. The cataloging of main module versions has to get better on the SBOM side. Current challenges exist for the Golang ecosystem summarized here: |
I think @willmurphyscode had a comment about understanding the new FP introduced here more concretely so I'll let him chime in before merging: FN ImpactQuery I put together to examine where we improve for this change:
Packages Impacted by potential False Negatives (Note: this change only affects results when they are the main module.)
So this has the potential to FIX 57 false negatives when those packages are the main module. I don't have a good impression with data that shows the false positive impact beyond my experimentation with the ollama image that showed how a potential new FP could be introduced. FP Impact@willmurphyscode had a good statement on the FP impact:
Final Thoughts (OPINION):I’m in favor of not tying improvements in Syft's Golang main module version discovery to this change. I think if a user brings an SBOM that was not generated with Syft, then grype should be considering all valid cases. Versions prefixed with Any introduction of FP is regrettable here, but if there are two outcomes for grype, then I’d rather go down the path where Grype is correct after considering all given valid version input for ANY given SBOM, rather than a narrow case where Grype trys to shore up edge cases of the main module version discovery in Syft’s Golang cataloger by not considering all options. |
Thanks for the investigation @spiffcs! I think @luhring is right that the I think I'm comfortable approving this because, without this change, Grype is effectively saying, "the sbom must be wrong; no one ships v0.0.0- main module versions," but sometimes there are |
Sounds good to me! Thanks for helping to vet this approach! |
This reverts commit 6dde5ce. Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
After my Grype PR (anchore/grype#1797), Anchore added a follow-up PR that makes this behavior cnofigurable. It is on by default for the Grype CLI but not for the Grype library. This commit enables it for the Grype library so we can see this kind of match from wolfictl scans. Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Previously, if Grype saw a Go binary's main module package version was set to a string prefixed by
v0.0.0-
, it would avoid any kind of vulnerability matching for that package.Meanwhile, Syft makes several reasonable attempts to find a sane version to use as this main module's version. In the case of VCS information being embedded in the Go binary, Syft has enough information to produce a Go pseudoversion.
The "no vulnerability matching at all" approach may have been to avoid some false positive edge cases, or it may have predated some of the enhancements to Syft's version computation. But in any case, we were seeing this behavior result in false negatives, because many Go projects produce Go binaries (and are thus the main module for that binary), and when Syft can compute a pseudoversion from VCS data, and these projects have GHSAs filed for them using pseudoversions (e.g. GHSA-xx8w-mq23-29g4), Grype was missing these matches 100% of the time.
To be upfront, I do expect this change to yield an increase in false positives. But I expect this change to yield a much bigger decrease in false negatives. If I understand the current Grype philosophy, distros with "comprehensive feeds" aren't even subject to this kind of matching, so it's really just the distros that are left (Wolfi, Chainguard, and Alpine), and then non-distro Go binaries where the developer is likely in much more control of the version information embedded in the binary.
For context, this change was discussed in advance in Anchore's community slack with @kzantow. (thread link)
Let me know if I can answer any questions!