Add Golang STD library package given a Golang binary has been discovered compiled with that go binary

[spiffcs]

What would you like to be added:

Even if an image/dir scan target does not have the Golang sdk installed, syft should still surface a package to represent the Golang standard library/version if a Golang binary is detected which was compiled using said std lib.

A good example of this use case can de demonstrated on syft itself:

syft -o json test-me | jq '.artifacts[1]'

{
  "id": "b852ba5e1335be1b",
  "name": "github.com/CycloneDX/cyclonedx-go",
  "version": "v0.7.1",
  "type": "go-module",
  "foundBy": "go-module-binary-cataloger",
  "locations": [
    {
      "path": "/Users/hal/GolandProjects/syft/test-me",
      "annotations": {
        "evidence": "primary"
      }
    }
  ],
  "licenses": [],
  "language": "go",
  "cpes": [
    "cpe:2.3:a:CycloneDX:cyclonedx-go:v0.7.1:*:*:*:*:*:*:*",
    "cpe:2.3:a:CycloneDX:cyclonedx_go:v0.7.1:*:*:*:*:*:*:*"
  ],
  "purl": "pkg:golang/github.com/CycloneDX/[email protected]",
  "metadataType": "GolangBinMetadata",
  "metadata": {
    "goCompiledVersion": "go1.19.5",
    "architecture": "amd64",
    "h1Digest": "h1:5w1SxjGm9MTMNTuRbEPyw21ObdbaagTWF/KfF0qHTRE=",
    "mainModule": "command-line-arguments"
  }
}

The above was discovered by the go-module-binary-cataloger

Given that we know the goCompiledVersion here is go1.19.5 we can add a package to the SBOM in the form of:

{
  "id": "xxxxxxxxxx",
  "name": "golang/go",
  "version": "1.19.5",
  "type": "go-module",
  "foundBy": "go-module-binary-cataloger",
  "locations": [],
  "licenses": [],
  "language": "go",
  "cpes": ["cpe:2.3:a:golang:go:*:*:*:*:*:*:*:*"],
  "purl": "",
  "metadataType": "",
  "metadata": { }
}

Open questions include:

• Should we add locations for each binary we discovered was compiled with said go version?
• What do the CPE look like for this?
• What does the PURL look like?
• What kind of metadata should exist for this package?

Context: https://anchorecommunity.slack.com/archives/C027JE5M345/p1685448982348869?thread_ts=1685374141.089149&cid=C027JE5M345

Why is this needed:
Allows users using SBOM to detect vulnerabilities like this one which should fire against the go binary itself, but is still valid given a program that was compiled with that binary:
https://nvd.nist.gov/vuln/detail/CVE-2022-23773

[jmartinc89]

I run syft against the golang:1.18 builder image (results are consistent against the 1.19.x branch) and I found the following two cpes:

cpe:2.3:a:golang:go:1.18.10:*:*:*:*:*:*:*",
cpe:2.3:a:go:go:1.18.10:*:*:*:*:*:*:*"]

I was expecting that the first were related to stdlib vulns and the other one for go sdk tools, but i found that https://nvd.nist.gov/vuln/detail/CVE-2018-7187 points to the first also. So I guess we cannot get rid of Go SDK false positives using this approach 😞

Purl was identified as "pkg:generic/go@${version}"

We are not procesing file locations nor artifact relationship right now, this is only ingested by grype later

I was trying a similar approach in my internal tests, but I set type attribute with a custom value, said "go-std", as is it later shown as it in the grype report and it is handy to identify the ones related to stdlibs, but i guess it is more like a hack than a supported feature 😉

[Brian-McM]

Is there any update on when this enhancement would done, or what the approach would look like?

Would this be a modification to the goBinaryCataloger cataloguer, or would the better approach be to piggy back off the goCompiledVersion included with the packages created by the goModCataloger?

[spiffcs]

@Brian-McM closed as of #2195
We should be releasing today.

It is a modification to the goBinaryCataloger as it stands now.

The jury is out on the goModCataloger as that is asserting a synthetic package that could potentially exist VS one that is actually linked inside the discovered artifact =)

[Brian-McM]

Not sure why I didn't see this sooner, but thanks @spiffcs. Just updated syft / grype and it works great!