Potential regression in CVE detection from 0.87.0 (v5 schema) to 0.88.0 (v6 schema) for go-module detection #2642

philroche · 2025-05-07T09:49:57Z

What happened:

Using grype 0.87.0 and the attached syft SBOM for a wolfi container image I see CVE GHSA-92cp-5422-2mw7 detected.

$ grype db status
Location:  /home/philroche/.cache/grype/db/5
Built:     2025-05-07 01:31:40 +0000 UTC
Schema:    5
Checksum:  sha256:794160408956b8a0e00b8161642b087058139ab49937ade5dd6849daaf357b5b
Status:    valid

$ grype --verbose ./traefik-3.2-pretty.json 
[0000]  INFO grype version: [not provided]
[0000]  WARN document has schema version 16.0.25, but parser has older schema version (16.0.20)
[0000]  INFO found 6 vulnerability matches across 326 packages
NAME                           INSTALLED  FIXED-IN  TYPE       VULNERABILITY        SEVERITY 
github.com/golang-jwt/jwt/v4   v4.5.1     4.5.2     go-module  GHSA-mh63-6h87-95cp  High      
github.com/golang-jwt/jwt/v5   v5.2.1     5.2.2     go-module  GHSA-mh63-6h87-95cp  High      
github.com/redis/go-redis/v9   v9.6.1     9.6.3     go-module  GHSA-92cp-5422-2mw7  Low       
github.com/traefik/traefik/v3  v3.2.5     3.3.6     go-module  GHSA-5423-jcjm-2gpv  Critical  
github.com/traefik/traefik/v3  v3.2.5     3.3.6     go-module  GHSA-6p68-w45g-48j7  High      
traefik-3.2                    3.2.5-r9             apk        CVE-2025-32431       High

I can also see the github.com/redis/go-redis/v9 go-module artifact present in the syft SBOM

    {
      "id": "cc1513ea4e8a3bd8",
      "name": "github.com/redis/go-redis/v9",
      "version": "v9.6.1",
      "type": "go-module",
      "foundBy": "go-module-binary-cataloger",
      "locations": [
        {
          "path": "/usr/bin/traefik",
          "layerID": "sha256:1e075dc4bba871594748c7c6f96dbfc4e4b00f9c311703c44ad6a5e1b01bb35a",
          "accessPath": "/usr/bin/traefik",
          "annotations": {
            "evidence": "primary"
          }
        }
      ],
      "licenses": [],
      "language": "go",
      "cpes": [
        {
          "cpe": "cpe:2.3:a:redis:go-redis\\/v9:v9.6.1:*:*:*:*:*:*:*",
          "source": "syft-generated"
        },
        {
          "cpe": "cpe:2.3:a:redis:go_redis\\/v9:v9.6.1:*:*:*:*:*:*:*",
          "source": "syft-generated"
        }
      ],
      "purl": "pkg:golang/github.com/redis/go-redis@v9.6.1#v9",
      "metadataType": "go-module-buildinfo-entry",
      "metadata": {
        "goCompiledVersion": "go1.24.2",
        "architecture": "amd64",
        "h1Digest": "h1:HHDteefn6ZkTtY5fGUE8tj8uy85AHk6zP7CpzIAM0y4=",
        "mainModule": "github.com/traefik/traefik/v3",
        "goCryptoSettings": [
          "standard-crypto"
        ]
      }
    },

BUT if I scan the same SBOM using grype 0.88.0 I do not see this CVE detected.

$ grype db status
Path:      /home/philroche/.cache/grype/db/6/vulnerability.db
Schema:    v6.0.2
Built:     2025-05-07T04:08:13Z
Checksum:  xxh64:a08f9e7f32e42e93
Status:    valid

$ grype --verbose ./traefik-3.2-pretty.json
[0000]  INFO grype version: [not provided]
[0000]  WARN document has schema version 16.0.25, but parser has older schema version (16.0.22)
[0000]  INFO ignored 1 vulnerability matches
[0000]  INFO found 5 vulnerability matches across 326 packages
NAME                           INSTALLED  FIXED-IN  TYPE       VULNERABILITY        SEVERITY 
github.com/golang-jwt/jwt/v4   v4.5.1     4.5.2     go-module  GHSA-mh63-6h87-95cp  High      
github.com/golang-jwt/jwt/v5   v5.2.1     5.2.2     go-module  GHSA-mh63-6h87-95cp  High      
github.com/traefik/traefik/v3  v3.2.5     3.3.6     go-module  GHSA-5423-jcjm-2gpv  Critical  
github.com/traefik/traefik/v3  v3.2.5     3.3.6     go-module  GHSA-6p68-w45g-48j7  High      
traefik-3.2                    3.2.5-r9             apk        CVE-2025-32431       High

The output does reference an ignored CVE but this is a different CVE - GHSA-3wqc-mwfx-672p

[0020]  INFO ignored 1 vulnerability matches
[0020] DEBUG   └── package=pkg:golang/github.com/traefik/traefik@v3.2.5#v3 rules=1 vuln=GHSA-3wqc-mwfx-672p

I see the same behaviour in later versions of grype but we were able to narrow the change down to the 0.88.0 release.

What you expected to happen:

I expect to see the same CVEs detected in the different versions of grype

How to reproduce it (as minimally and precisely as possible):

git checkout v0.87.0
go install ./cmd/grype
grype db update 
grype db status
grype --verbose ./traefik-3.2-pretty.json

# Observe results
git checkout v0.88.0
go install ./cmd/grype
grype db update 
grype db status
grype --verbose ./traefik-3.2-pretty.json
# Observe results

I have attached the grype scan results and verbose logs for both scans.

Anything else we need to know?:

This is concerning as we could be missing valid detections. The syft SBOM does find the vulnerable component version present yet grype does not detect it as a CVE.

Environment:

Output of grype version: Multiple versions installed from git tag.
OS (e.g: cat /etc/os-release or similar):

cat /etc/os-release                                                                                                            
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

traefik-3.2-pretty.json

grype-0.87.0-scan-traefik-3.2-pretty.json
grype-0.88.0-scan-traefik-3.2-pretty.json
grype-0.87.0-scan-traefik-3.2.log
grype-0.88.0-scan-traefik-3.2.log

The text was updated successfully, but these errors were encountered:

kzantow · 2025-05-07T13:23:22Z

A cursory look (thanks @westonsteimel!) shows that there's a version constraint which fails to parse, perhaps due to a recent change to the golang version parsing using semver: https://github.com/anchore/grype/blob/main/grype/version/golang_version.go#L35:

[0000] DEBUG unable to parse constraint constraint=>=9.6.0b1,<9.6.3 error=failed to create comparator for '&{>= 9.6.0b1}': unable to parse Golang constraint version (9.6.0b1): Malformed version: 9.6.0b1 format=go

willmurphyscode · 2025-05-08T00:07:04Z

TL;DR

The version constraint on the GHSA doesn't point to a valid Go package version, but does point to a real git tag. The path forward is to make Grype fall back to fuzzier version matching logic in this edge case, and possibly open an issue with GHSA to see whether that version constraint is correct.

Long version

I've gathered a little bit more information here:

This wasn't introduced by the recent change to go semver. It was changed by the rewrite of the search functions from grype db schema v5 to v6. (That doesn't really change what to do; just validating where it is.)
GHSA-92cp-5422-2mw7 has a version constraint that can't be parsed, because 9.6.0b1 is not a real go semantic version.
However, 9.6.0b1 is a real release of the product, or at least a pre-release: https://github.com/redis/go-redis/releases/tag/v9.6.0b1
Future pre-releases of the go-redis are semver compliant, e.g. https://github.com/redis/go-redis/releases/tag/v9.8.0-beta.1 which has the mandatory hyphen separating major.minor.patch from the prerelease designation, so it's sort of bad luck that there was a GHSA fixed in a git tag that's not a valid go version.
You can't go get version 9.6.0b1 and end up with that in the go mod. If you try go get github.com/redis/go-redis/v9@v9.6.0b1, you end up with this (pseudo?) version that seems to be a commit SHA after the last semver compliant git tag: go: added github.com/redis/go-redis/v9 v9.5.3-0.20240619233258-1c0efc2325ad.

Because of item 5, it might be worth opening an issue with GHSA and seeing whether we can put v9.5.3-0.20240619233258-1c0efc2325ad in the version constraint. AFAICT that's what we'll always see in the wild.

To see whether there are other GHSAs in a similar boat, I instrumented grype-db so that it would try to parse constraints when writing them into the database, and note any time it was emitting an invalid constraint. This only happens a handful of times. Of those, two are for Go issues:

GHSA-8r25-68wm-jw35 which is wrong; the correct release for it to point to is probably https://github.com/0xJacky/nginx-ui/releases/tag/v2.0.0-beta.9 (though I can't go get that one either, the tag v2.0.0.beta.9 is not present in the repo so it probably shouldn't be a tag on the GHSA. I'm happy to send a PR for that unless someone beats me to it.
The other one is GHSA-92cp-5422-2mw7 (the one reported in this issue, discussed above).

To defend against this in the future, we'll put logic in grype to fall back to the "fuzzy" version comparator in cases where we can't parse the version constraint (or package version) in line with its advertised type.

Additionally, this research led me to find a handful of Ruby GHSAs in a similar boat, tracked separately at #2646

philroche · 2025-05-08T08:50:17Z

Thank you for the detailed analysis. I am glad you have identified this as an edge case.

willmurphyscode · 2025-05-14T09:19:52Z

This is fixed in today's grype db due to anchore/grype-db#574 taking effect and telling grype to use the "fuzzy" version matcher in the case that upstream data can't be parsed as an ecosystem specific version constraint.

Client side changes that should make grype more resilient to this kind of data weirdness have landed in #2651 as well, which should be released soon.

philroche · 2025-05-14T09:21:05Z

Thank you @willmurphyscode

philroche added the bug Something isn't working label May 7, 2025

kzantow added the needs-investigation label May 7, 2025

willmurphyscode self-assigned this May 7, 2025

willmurphyscode added this to OSS May 7, 2025

willmurphyscode moved this to In Progress in OSS May 7, 2025

willmurphyscode mentioned this issue May 9, 2025

fix: fall back to fuzzy constraint units #2651

Merged

willmurphyscode closed this as completed May 14, 2025

github-project-automation bot moved this from In Progress to Done in OSS May 14, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Potential regression in CVE detection from 0.87.0 (v5 schema) to 0.88.0 (v6 schema) for go-module detection #2642

Potential regression in CVE detection from 0.87.0 (v5 schema) to 0.88.0 (v6 schema) for go-module detection #2642

Potential regression in CVE detection from 0.87.0 (v5 schema) to 0.88.0 (v6 schema) for go-module detection #2642

Potential regression in CVE detection from 0.87.0 (v5 schema) to 0.88.0 (v6 schema) for go-module detection #2642

Comments

TL;DR

Long version