CVE-2022-23498 not being reported by Grype (for Grafana@9.2.4)

[bturner-cpacket]

What happened:
I run Grype over Grafana 9.2.4 and it fails to report CVE-2022-23498

What you expected to happen:
I expected to see CVE-2022-23498 reported as the vulnerability is in 9.2.4:

Package

Affected versions   >=8.3.0-beta1
Patched versions    9.3.4, 9.2.10

How to reproduce it (as minimally and precisely as possible):
We do this:
FROM ${docker_registry}grafana/grafana:9.2.4 as stable

Then we use Syft to generate an SBOM on this container. Then we use Grype to scan the SBOM.

Anything else we need to know?:

We generate an SBOM for this and that SBOM has the following information in it related to Grafana (pay attention to the version):

{
   "id": "e0096f6e58724f2e",
   "name": "github.com/grafana/grafana",
   "version": "v0.0.0-20221108103842-64017e8ca682",
   "type": "go-module",
   "foundBy": "go-module-binary-cataloger",
   "locations": [
    {
     "path": "/usr/share/grafana/bin/grafana-cli",
     "layerID": "sha256:245c77c48e91231cb9493c35992535f049af4cfa20a2300cf872fa1ed28d0133"
    }
   ],
   "licenses": [],
   "language": "go",
   "cpes": [
    "cpe:2.3:a:grafana:grafana:v0.0.0-20221108103842-64017e8ca682:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:golang/github.com/grafana/grafana@v0.0.0-20221108103842-64017e8ca682",
   "metadataType": "GolangBinMetadata",
   "metadata": {
    "goBuildSettings": {
     "-compiler": "gc",
     "-ldflags": "-linkmode=external -extldflags=-static -w -X main.version=9.2.4 -X main.commit=64017e8ca6 -X main.buildstamp=1667903922 -X main.buildBranch=HEAD",
     "CGO_CFLAGS": "",
     "CGO_CPPFLAGS": "",
     "CGO_CXXFLAGS": "",
     "CGO_ENABLED": "1",
     "CGO_LDFLAGS": "",
     "GOAMD64": "v1",
     "GOARCH": "amd64",
     "GOOS": "linux",
     "vcs": "git",
     "vcs.modified": "false",
     "vcs.revision": "64017e8ca6825b79a2acb887a1c1d9088e47ed72",
     "vcs.time": "2022-11-08T10:38:42Z"
    },
    "goCompiledVersion": "go1.19.3",
    "architecture": "amd64",
    "mainModule": "github.com/grafana/grafana"
   }
  },

In this sbom, other than a linker flag pointing out the main.version=9.2.4 , all the version information looks more like this:
grafana:v0.0.0-20221108103842-64017e8ca682

If we scan the sbom with v0.0.0 we see these results:

% grype sbom:./grafana-sbom.json
 ✔ Vulnerability DB        [no update available]
New version of grype is available: 0.57.0 (currently running: 0.51.0)
 ✔ Scanned image           

NAME                                    INSTALLED                             FIXED-IN  TYPE       VULNERABILITY        SEVERITY

If we manually go and change those versions from v0.0.0 to v9.2.4 in the SBOM and then scan again, we see the vulnerabilities:

grype sbom:./grafana-sbom.json
 ✔ Vulnerability DB        [no update available]
New version of grype is available: 0.57.0 (currently running: 0.51.0)
 ✔ Scanned image           
NAME                                    INSTALLED                             FIXED-IN  TYPE       VULNERABILITY        SEVERITY
github.com/grafana/grafana              v9.2.4-20221108103842-64017e8ca682              go-module  CVE-2022-23552       Medium
github.com/grafana/grafana              v9.2.4-20221108103842-64017e8ca682              go-module  CVE-2022-23498       High
github.com/grafana/grafana              v9.2.4-20221108103842-64017e8ca682              go-module  CVE-2022-39324       Low

This issue seems to point out a similar issue for a different vendor?

Grype’s vulnerability database needing to be updated to include all the "v0.0.0-*" version strings that fall between the affected versions.

It would be easy to say that Grafana should fix their build process but I don’t think thats how security issues get addresses. If its already out there in the wild then the vulnerability still needs to be caught even when the version string is wrong.

Environment:

• Output of grype version:
  0.51.0
• OS (e.g: cat /etc/os-release or similar):
  Linux 5.4.0-1088-aws #96~18.04.1-Ubuntu SMP Mon Oct 17 02:57:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

[wagoodman]

Hey! This is a known limitation with go modules, where the version of the go module that represents the main package (not a dependency) is not available in the binary in a standard way (see golang/go#29228). Note that the version found by grype/syft is v0.0.0-20221108103842-64017e8ca682 , which is correct in the artifact --that means that there isn't anything actionable today based on the capabilities of syft to fix this.

That being said, take a close look at the ldflags available in the package metadata:

     "-ldflags": "... -X main.version=9.2.4 ...",

We have been pondering about adding additional capabilities in syft that would, in fuzzy fashion, attempt to extract version-like things for main modules found as ldflags. This would be a best-effort attempt and not perfect (since there could be any structure to these flags)... @westonsteimel has taken an initial stab at this here https://github.com/anchore/syft/compare/extract-go-binary-versions-from-known-build-flags .

This would be one way to solve this problem.

[bturner-cpacket]

Hey! This is a known limitation with go modules, where the version of the go module that represents the main package (not a dependency) is not available in the binary in a standard way (see golang/go#29228). Note that the version found by grype/syft is v0.0.0-20221108103842-64017e8ca682 , which is correct in the artifact --that means that there isn't anything actionable today based on the capabilities of syft to fix this.

That being said, take a close look at the ldflags available in the package metadata:

     "-ldflags": "... -X main.version=9.2.4 ...",

We have been pondering about adding additional capabilities in syft that would, in fuzzy fashion, attempt to extract version-like things for main modules found as ldflags. This would be a best-effort attempt and not perfect (since there could be any structure to these flags)... @westonsteimel has taken an initial stab at this here https://github.com/anchore/syft/compare/extract-go-binary-versions-from-known-build-flags .

This would be one way to solve this problem.

I've been pondering this for a bit and I think I like it, but I am not sure I can think enough about all the edge cases to say that this is the right answer. The thread at golang/go#29228 is really something!

[tgerla]

Hi @bturner-cpacket, we just did a little bit of testing and it looks like anchore/syft#1785 fixes this particular problem, so I will go ahead and close this issue. Please let us know if anything else comes up and we can take a look. Thanks!

[bturner-cpacket]

@tgerla - This is great, I will give this a try and let you know if anything additional comes up. Thanks!