Using replace in a go.mod creates a SPDX package without versionInfo (Non-NTIA compliant)

[edonadei]

What happened:
In the case of scanning a Go project with a go.mod file with a replace statement, e.g. here. It supposed to recursively resolve to this file.

But it generates a sbom package without versionInfo. (Non-NTIA Compliant)

{
   "name": "../",
   "SPDXID": "SPDXRef-Package-go-module-..--dd9d9dcfff65b1c8",
   "downloadLocation": "NOASSERTION",
   "sourceInfo": "acquired package info from go module information: gopls/go.mod",
   "licenseConcluded": "NONE",
   "licenseDeclared": "NONE",
   "copyrightText": "NOASSERTION",
   "externalRefs": [
    {
     "referenceCategory": "PACKAGE-MANAGER",
     "referenceType": "purl",
     "referenceLocator": "pkg:golang/..",
     "comment": ""
    }
   ]
  },

What you expected to happen:

The package refered here is already added

{
   "name": "golang.org/x/tools",
   "SPDXID": "SPDXRef-Package-go-module-golang.org-x-tools-1f460cef42bec5c6",
   "versionInfo": "v0.6.0",
   "downloadLocation": "NOASSERTION",
   "sourceInfo": "acquired package info from go module information: gopls/go.mod",
   "licenseConcluded": "NONE",
   "licenseDeclared": "NONE",
   "copyrightText": "NOASSERTION",
   "externalRefs": [
    {
     "referenceCategory": "SECURITY",
     "referenceType": "cpe23Type",
     "referenceLocator": "cpe:2.3:a:golang:x\\/tools:v0.6.0:*:*:*:*:*:*:*",
     "comment": ""
    },
    {
     "referenceCategory": "PACKAGE-MANAGER",
     "referenceType": "purl",
     "referenceLocator": "pkg:golang/golang.org/x/tools@v0.6.0",
     "comment": ""
    }
   ]
  },

So I would expect that package "../" to not exist at all.

Steps to reproduce the issue:

git clone https://github.com/golang/tools.git
cd tools
syft .

Anything else we need to know?:
I used this checker to verify if the SBOM is compliant https://github.com/spdx/ntia-conformance-checker

Environment:

• Output of syft version: v.0.77.0
• OS (e.g: cat /etc/os-release or similar): Ubuntu

[tgerla]

Hey @edonadei, thanks for the report. I think we understand the problem well enough so we'll put it in our backlog for consideration. There is a caveat that if we are unable to determine the version at all, we will probably still have to create non-NTIA-compliant output because we just don't have any version to reference.

Implementation notes: we might need to implement a "replace" handler to figure out how to do the right thing in these cases.