Set version of top-level library component in SBOM

[pringon]

What happened?

• What were you attempting to do?

Merge CycloneDX SBOM from the go-build buildpack with the others SBOMs that I am producing into a final, shippable, SBOM.

• What did you expect to happen?

Have a valid SBOM that I can use. The SBOM would contain the software dependencies that went into my build as items in the top-level components list. They would all contain expected fields such as purl, type, name, and version with sensible values.

• What was the actual behavior? Please provide log output, if possible.

The go-build SBOM includes the built library as the first component with an empty string for the version, this got erased by my merger and that lead to an SBOM validation failure because there was a component with no version.

Example SBOM:

  "components": [
    {
      "type": "library",
      "name": "toy-go-project",
      "version": "",
      "purl": "pkg:golang/toy-go-project/toy-go-project",
      "properties": [...]
    },
    {
      "type": "library",
      "name": "github.com/BurntSushi/toml",
      "version": "v0.3.1",
      "cpe": "cpe:2.3:a:BurntSushi:toml:v0.3.1:*:*:*:*:*:*:*",
      "purl": "pkg:golang/github.com/BurntSushi/toml@v0.3.1",
      "properties": [...]
    }
  ]

Note the empty version field in the toy-go-project component.

• Suggestions

Have the library's version be set to latest or another sensible default or allow setting it in project.toml.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

  Pack v0.24.0

• What buildpacks are you using? Please include versions.

• go-dist 1.1.0
• go-mod-vendor 0.6.0
• go-build 1.1.1

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

  N/A

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

N/A

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

[fg-j]

Hi there. Thanks for the feedback! Since the Paketo buildpacks rely on Syft to generate SBOMS from Go binaries, I believe this fix would need to be implemented upstream in syft. Fortunately, there's already an issue (anchore/syft#894) open against Syft to make this change.

Once the fix is available upstream, we'll be able to pull it into the buildpacks.

[ryanmoran]

While this is pending, I have a hack that could resolve this. Should I open a PR against our code in packit?

diff --git a/sbom/internal/formats/cyclonedx13/cyclonedxhelpers/component.go b/sbom/internal/formats/cyclonedx13/cyclonedxhelpers/component.go
index 5f173ac..3d042ba 100644
--- a/sbom/internal/formats/cyclonedx13/cyclonedxhelpers/component.go
+++ b/sbom/internal/formats/cyclonedx13/cyclonedxhelpers/component.go
@@ -22,11 +22,20 @@ func encodeComponent(p pkg.Package) cyclonedx.Component {
                properties = &props
        }

+       version := p.Version
+       if version == "" {
+               if metadata, ok := p.Metadata.(pkg.GolangBinMetadata); ok {
+                       if len(metadata.BuildSettings) > 0 {
+                               version = "(devel)"
+                       }
+               }
+       }
+
        return cyclonedx.Component{
                Type:               cyclonedx.ComponentTypeLibrary,
                Name:               p.Name,
                Group:              encodeGroup(p),
-               Version:            p.Version,
+               Version:            version,
                PackageURL:         p.PURL,
                Licenses:           encodeLicenses(p),
                CPE:                encodeSingleCPE(p),

[pringon]

Hey, thanks for the swift reply 😄

I will leave it up to you whether to put that workaround in or not.

@fg-j I was aware that this was related to syft but I didn't find that issue from my research, thanks for sharing it. It's relevant to note that this issue is most significant in go1.17 since vcs information is no passed to go build there. I fixed the main problem I was experiencing by compiling with go1.18 instead.

Another problem to consider is that buildpacks' include semantics could still break versioning since users may exclude their .git repository from the build. Is that something we want to consider a possible fix for?

A colleague mentioned the idea of using a checksum for the binary's version instead of the revisionId. I would be happy to help with implementing the fix upstream if offered some guidance and opinions from the community. Thought I would write on this issue first to get the paketo community's opinion on the matter before spamming the syft discussion. 😁

[robdimsdale]

I'm going to close this as there's been no activity in over a year. As far as I can tell, it looks like at least part of this issue was resolved in the upstream syft library.

If I'm wrong, or there's other aspects to this issue that are still relevant and actionable, please feel free to re-open.