Go module pseudo-version false positives
👋 Hello!
We have observed a recurring false positive issue when go.mod files utilize pseudo-versions.
Additional Context
This looks like it was brought up previously in https://github.com/google/osv-scanner/issues/491 and https://github.com/google/osv-scanner/issues/910 but were seemingly unresolved. Additionally, it seems that Dependabot doesn't really support this either: https://github.com/dependabot/dependabot-core/issues/2028 🤷
Problem
Go pseudo-versions introduce challenges in vulnerability management workflows. These versions can create confusion for engineers when triaging results, leading to inefficiencies stemmed from false positives, and potential misinterpretations of vulnerability data.
Example
GHSA-5jp2-vwrj-99rf is reported in github.com/concourse/[email protected]:
╭─────────────────────────────────────┬──────┬───────────┬────────────────────────────────┬─────────────────────────────────────┬────────╮
│ OSV URL │ CVSS │ ECOSYSTEM │ PACKAGE │ VERSION │ SOURCE │
├─────────────────────────────────────┼──────┼───────────┼────────────────────────────────┼─────────────────────────────────────┼────────┤
│ https://osv.dev/GHSA-5jp2-vwrj-99rf │ 5.4 │ Go │ github.com/concourse/concourse │ 1.6.1-0.20230608160752-b14acb611a79 │ go.mod │
╰─────────────────────────────────────┴──────┴───────────┴────────────────────────────────┴─────────────────────────────────────┴────────╯
However, the pseudo-version is technically higher than the one in the patched versions:
[!IMPORTANT] The pseudo version (
v1.6.1-0.20230608160752-b14acb611a79) does not correspond to a tag in the same semantic version range, which makes things extra confusing.https://github.com/concourse/concourse/releases/tag/v1.6.1 👈 This 404s, not a thing;
v2.0.0was published afterv1.6.0.![]()
It's this commit (used by the go toolchain): https://github.com/concourse/concourse/commit/b14acb611a79
Which maps to this released version: https://github.com/concourse/concourse/releases/tag/v7.10.0
And can be verified with git using:
$ git clone https://github.com/concourse/concourse.git
$ cd concourse
$ git describe --contains b14acb611a79
v7.10.0~11
[!NOTE] We can identify pseudo-versions using
golang.org/x/mod/module.IsPseudoVersionto avoid sending these to the OSV API altogether as an intermediate fix. But, it might be required to usego-git(or equivalent) to inspect the repository's commit history to identify a released tag (if there is even one at all). It's possible that pseudo-versions don't map back to a released version at all (especially prevalent forv0.0.0-*variants).
This seems like it's also a osv.dev issue, where we should enumerate all the git commits then match against those when given a pseudoversion.
Can you give me a bit more detail on how this version is created?
Was it manually updated to this version, or is there a go get command that somehow created this go.mod entry with the wrong tag?
🤷 Unfortunately, I'm not totally sure how this version was created. Just found it "in the wild". Looking at git blame, seems like it was included in a go.mod file two years ago when it was originally added.
Ok, I think we figured out what is happening here. github.com/concourse/concourse technically does not have version 6.7.9, 7.0.0...etc if we are talking about go packages. See https://pkg.go.dev/github.com/concourse/concourse?tab=versions
This is because to bump up a major version in go, you have to update your module name to also include /v2, v3, v4... For example: github.com/concourse/concourse/v7, which they have not done.
So all tags after v1.6.0 simply do not exist according to go, so to use the newer versions you have to use a pseudo-version. This means technically the GHSA records are invalid, since they are describing ranges that do not exist in the Go ecosystem.
We'll have a look to see how common this actually is in our database for Go, and decide what to do from there.
@another-rex thank you for tracking that down! Have ya'll had a chance to determine how common this is yet, or is there any way I can help?
Answer is that there are around 45 records with this issue:
--- Summary ---
Found 45 file(s) that has affect packages with major version different from module version:
- https://osv.dev/GHSA-jr9x-3x7m-4j75
- https://osv.dev/GHSA-9fpw-c9x7-cv3j
- https://osv.dev/GHSA-6m9f-pj6w-w87g
- https://osv.dev/GHSA-vg67-chm7-8m3j
- https://osv.dev/GHSA-r67m-mf7v-qp7j
- https://osv.dev/GHSA-6p4m-hw2h-6gmw
- https://osv.dev/GHSA-567v-6hmg-6qg7
- https://osv.dev/GHSA-m5vv-6r4h-3vj9
- https://osv.dev/GHSA-x9qq-236j-gj97
- https://osv.dev/GHSA-wxcc-2f3q-4h58
- https://osv.dev/GHSA-gr79-9v6v-gc9r
- https://osv.dev/GHSA-455c-vqrf-mghr
- https://osv.dev/GHSA-3wq5-3f56-v5xc
- https://osv.dev/GHSA-qppj-fm5r-hxr3
- https://osv.dev/GHSA-2549-xh72-qrpm
- https://osv.dev/GHSA-vvpg-55p7-5h8w
- https://osv.dev/GHSA-vg6q-84p8-qvqh
- https://osv.dev/GHSA-627p-rr78-99rj
- https://osv.dev/GHSA-5844-q3fc-56rh
- https://osv.dev/GHSA-w496-f5qq-m58j
- https://osv.dev/GHSA-hfrg-4jwr-jfpj
- https://osv.dev/GHSA-jwvw-v7c5-m82h
- https://osv.dev/GHSA-77rm-9x9h-xj3g
- https://osv.dev/GHSA-vx57-7f4q-fpc7
- https://osv.dev/GHSA-63f2-6959-2pxj
- https://osv.dev/GHSA-rp74-x43m-cpw3
- https://osv.dev/GHSA-762m-4cx6-6mf4
- https://osv.dev/GHSA-xr7p-8q82-878q
- https://osv.dev/GHSA-v333-7h2p-5fhv
- https://osv.dev/GHSA-3gpx-p63p-pr5r
- https://osv.dev/GHSA-hh8p-374f-qgr5
- https://osv.dev/GHSA-c8xw-vjgf-94hr
- https://osv.dev/GHSA-6cf5-w9h3-4rqv
- https://osv.dev/GHSA-xvq6-h898-wcj8
- https://osv.dev/GHSA-r6cc-7wj7-gfx2
- https://osv.dev/GHSA-f2wr-c4c4-xjg7
- https://osv.dev/GHSA-cmc8-222c-vqp9
- https://osv.dev/GHSA-4v65-xqcj-wpgg
- https://osv.dev/GHSA-jq3g-xqpx-37x3
- https://osv.dev/GHSA-45x7-px36-x8w8
- https://osv.dev/GHSA-56mc-f9w7-2wxq
- https://osv.dev/GHSA-4whx-7p29-mq22
- https://osv.dev/GHSA-j7hp-h8jx-5ppr
- https://osv.dev/GHSA-72qv-j8vr-xvfv
- https://osv.dev/GHSA-mx2j-7cmv-353c
We'll work with github to try and get these resolved.
It does seem like Go's own advisories don't have this issue though.
This issue has not had any activity for 60 days and will be automatically closed in two weeks
See https://github.com/google/osv-scanner/blob/main/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.
@another-rex should we keep this issue open?
Go pseudoversion matching is still a feature we might want, so we'll keep it as a backlog for now.
Sounds good, thank you @another-rex and @cuixq!