Guess go main module version based on binary contents

[wagoodman]

Today the go main module version cannot be determined in all cases. We have a few heuristics in place to try and guess what the main module version is (by looking at ldflags and build setting info), however, there are still cases that are missed:

# as it is today...
❯ syft -q registry.k8s.io/ingress-nginx/controller:v1.6.4 | grep k8s.io/ingress-nginx
k8s.io/ingress-nginx                              (devel)                               go-module

This PR adds an additional heuristic to look at the binary contents and use a simple semver regex pattern matcher like we do with the binary cataloger to find matching version strings:

# with the code change...
❯ go run ./cmd/syft -q registry.k8s.io/ingress-nginx/controller:v1.6.4 | grep k8s.io/ingress-nginx
k8s.io/ingress-nginx                              (devel)                               go-module
k8s.io/ingress-nginx                              v1.6.4                                go-module

You'll note that it seems like it only "kind of" worked -- now we have two k8s.io/ingress-nginx packages, one that is correct and another that still shows devel. In this particular case, this is the best we can do. Let's look at what was found in detail:

# with the code change...
❯ go run ./cmd/syft -q registry.k8s.io/ingress-nginx/controller:v1.6.4 -o json | jq '.artifacts[] | select(.name == "k8s.io/ingress-nginx") | {name: .name, version: .version, locations: .locations}'

{
  "name": "k8s.io/ingress-nginx",
  "version": "(devel)",
  "locations": [
    {
      "path": "/dbg",
      "layerID": "sha256:fcc6781a7edaf8fa9971199d0c361dd3a0bebd6d76805a2d3cd41ff5b477a380",
      "accessPath": "/dbg",
      "annotations": {
        "evidence": "primary"
      }
    }
  ]
}
{
  "name": "k8s.io/ingress-nginx",
  "version": "(devel)",
  "locations": [
    {
      "path": "/wait-shutdown",
      "layerID": "sha256:ac97db116c0d5573f76be38bfa782acf196ec1ed83ba753546479a4732f8e5cc",
      "accessPath": "/wait-shutdown",
      "annotations": {
        "evidence": "primary"
      }
    }
  ]
}
{
  "name": "k8s.io/ingress-nginx",
  "version": "v1.6.4",
  "locations": [
    {
      "path": "/nginx-ingress-controller",
      "layerID": "sha256:56b71709a8bf999f9a65d21e58cad1be7a521c0718981b98a0032b38eb9c5338",
      "accessPath": "/nginx-ingress-controller",
      "annotations": {
        "evidence": "primary"
      }
    }
  ]
}

There are three different binaries that have the same k8s.io/ingress-nginx package: /nginx-ingress-controller, /wait-shutdown, /dbg.

It seems that only the main /nginx-ingress-controller binary has any indication of a version baked into the binary:

❯ strings nginx-ingress-controller | grep '1\.6\.4'
v1.6.4
❯ strings dbg | grep '1\.6\.4'
❯ strings wait-shutdown | grep '1\.6\.4'

In the future we might be able to correlate claimed package h1 information across all main packages discovered to try and get a better answer for all packages, but that is out of scope for this particular enhancement (and may be questionable to do , thus requires some discussion first). -- nevermind, I forgot there is no h1 digest for the main module

[wagoodman]

Question for reviewers: since this has the potential to raise up an incorrect version on a package, should this at least have a configuration option that a user can opt out of this heuristic?

[westonsteimel]

A config option seems like a good idea to me; however should it also apply or have subcomponents to also enable/disable the parsing of version from ldflags etc since that also has the potential to be incorrect?

[wagoodman]

I've added configuration options for all version guessing heuristics since they can all really have downsides. They all default to enabled.

[wagoodman]

adjusts the pattern to be more permissive based on examples in the field. This allows for us to depend on the (probably more dependable) LD flags instead of the binary contents pattern matching in more cases.