Different naming of Golang standard library between trivy and cyclonedx-gomod

[beatrausch]

Description

When running trivy and cyclonedx-gomod to generate SBOMs different names for the golang standard libraray component are assigned. This makes merging of SBOMs only possible with a hard coded list of alternative names.

Desired Behavior

Both trivy and cyclonedx-gomod assign the same name for the golang standard library stdlib to allow proper merging of SBOMs. Trivy uses the same identifier as the Go team does for vulnerabilities, e,g check.

Actual Behavior

The golang standard library is named as follows:

trivy: stdlib

{
      "bom-ref": "pkg:golang/stdlib@1.23.4",
      "type": "library",
      "name": "stdlib",
      "version": "1.23.4",
      "purl": "pkg:golang/stdlib@1.23.4",
      "properties": [
        {
          "name": "aquasecurity:trivy:LayerDiffID",
          "value": "sha256:f75706aada560f9fc3c035a44e9c8f8da8bf7317a39df18ae86c56fdd8344d66"
        },
        {
          "name": "aquasecurity:trivy:LayerDigest",
          "value": "sha256:9f888a47f0b0f4ecd36abfd90d4a77bc93fcedb6135f4d24fd36b6d6b232533c"
        },
        {
          "name": "aquasecurity:trivy:PkgType",
          "value": "gobinary"
        }
      ]
 },

cyclonedx-gomod: std

{
      "bom-ref": "pkg:golang/std@go1.23.4?type=module",
      "type": "library",
      "name": "std",
      "version": "go1.23.4",
      "scope": "required",
      "purl": "pkg:golang/std@go1.23.4?type=module\u0026goos=linux\u0026goarch=amd64"
},

Reproduction Steps

Create SBOM from trivy source code (v0.59.0)

1. cyclonedx-gomod app -json -output cdx.sbom.json -std -main cmd/trivy
2. trivy image --format cyclonedx --output trivy.sbom.json aquasec/trivy:0.59.0

[stevespringett]

Isn’t the name of the package std?
https://pkg.go.dev/std

stdlib isn’t a valid package name.
https://pkg.go.dev/stdlib

Unless I’m completely missing something, it appears that the Go team is using the wrong package name and Trivy is asserting an incorrect identifier for std to account for that.

If that is the case, the fix would not be to introduce a defect into the CycloneDX implementation, but to fix the root cause.

[beatrausch]

Thx, for the quick response!

I did some searching in the Golang sources and I think I found the proof that std is correct as you mentioned. The module itself is called std.

Also still not sure what it means for the go vuln project, or if there is another naming for vulnerabilities of the standard library.

[beatrausch]

Hi,

got feedback from the trivy team:

The Go team distinguishes stdlib and toolchain. Since we detect Go vulnerabilities in standard libraries, not toolchains, we need to use stdlib.

I also tried to scan CVEs with the different names:

PURL with stdlib

curl -d @stdlib.json https://api.osv.dev/v1/query

stdlib.json

{ 
  "package": {
    "purl": "pkg:golang/stdlib@1.23.4"
  }
}

Result

{"vulns":[{"id":"GO-2025-3373","summary":"Usage of IPv6 zone IDs can bypass URI name constraints in crypto/x509","details":"A certificate with a URI which has a IPv6 address with a zone ID may incorrectly satisfy a URI name constraint that applies to the certificate chain.\n\nCertificates containing URIs are not permitted in the web PKI, so this only affects users of private PKIs which make use of URIs.","aliases":["BIT-golang-2024-45341","CVE-2024-45341"],"modified":"2025-01-30T20:12:14.327943Z","published":"2025-01-28T00:47:30Z","database_specific":{"url":"https://pkg.go.dev/vuln/GO-2025-3373","review_status":"REVIEWED"},"references":[{"type":"FIX","url":"https://go.dev/cl/643099"},{"type":"REPORT","url":"https://go.dev/issue/71156"},{"type":"WEB","url":"https://groups.google.com/g/golang-dev/c/bG8cv1muIBM/m/G461hA6lCgAJ"},{"type":"WEB","url":"https://groups.google.com/g/golang-dev/c/CAWXhan3Jww/m/bk9LAa-lCgAJ"}],"affected":[{"package":{"name":"stdlib","ecosystem":"Go","purl":"pkg:golang/stdlib"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.22.11"},{"introduced":"1.23.0-0"},{"fixed":"1.23.5"},{"introduced":"1.24.0-0"},{"fixed":"1.24.0-rc.2"}]}],"ecosystem_specific":{"imports":[{"symbols":["CertPool.AppendCertsFromPEM","Certificate.CheckCRLSignature","Certificate.CheckSignature","Certificate.CheckSignatureFrom","Certificate.CreateCRL","Certificate.Verify","Certificate.VerifyHostname","CertificateRequest.CheckSignature","CreateCertificate","CreateCertificateRequest","CreateRevocationList","DecryptPEMBlock","EncryptPEMBlock","HostnameError.Error","MarshalECPrivateKey","MarshalPKCS1PrivateKey","MarshalPKCS1PublicKey","MarshalPKCS8PrivateKey","MarshalPKIXPublicKey","ParseCRL","ParseCertificate","ParseCertificateRequest","ParseCertificates","ParseDERCRL","ParseECPrivateKey","ParsePKCS1PrivateKey","ParsePKCS1PublicKey","ParsePKCS8PrivateKey","ParsePKIXPublicKey","ParseRevocationList","RevocationList.CheckSignatureFrom","SetFallbackRoots","SystemCertPool","matchURIConstraint"],"path":"crypto/x509"}]},"database_specific":{"source":"https://vuln.go.dev/ID/GO-2025-3373.json"}}],"schema_version":"1.6.0","credits":[{"name":"Juho Forsén of Mattermost"}]},{"id":"GO-2025-3420","summary":"Sensitive headers incorrectly sent after cross-domain redirect in net/http","details":"The HTTP client drops sensitive headers after following a cross-domain redirect. For example, a request to a.com/ containing an Authorization header which is redirected to b.com/ will not send that header to b.com.\n\nIn the event that the client received a subsequent same-domain redirect, however, the sensitive headers would be restored. For example, a chain of redirects from a.com/, to b.com/1, and finally to b.com/2 would incorrectly send the Authorization header to b.com/2.","aliases":["BIT-golang-2024-45336","CVE-2024-45336"],"modified":"2025-01-30T20:12:08.973745Z","published":"2025-01-28T00:47:30Z","database_specific":{"url":"https://pkg.go.dev/vuln/GO-2025-3420","review_status":"REVIEWED"},"references":[{"type":"FIX","url":"https://go.dev/cl/643100"},{"type":"REPORT","url":"https://go.dev/issue/70530"},{"type":"WEB","url":"https://groups.google.com/g/golang-dev/c/CAWXhan3Jww/m/bk9LAa-lCgAJ"},{"type":"WEB","url":"https://groups.google.com/g/golang-dev/c/bG8cv1muIBM/m/G461hA6lCgAJ"}],"affected":[{"package":{"name":"stdlib","ecosystem":"Go","purl":"pkg:golang/stdlib"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.22.11"},{"introduced":"1.23.0-0"},{"fixed":"1.23.5"},{"introduced":"1.24.0-0"},{"fixed":"1.24.0-rc.2"}]}],"ecosystem_specific":{"imports":[{"symbols":["Client.Do","Client.Get","Client.Head","Client.Post","Client.PostForm","Client.do","Client.makeHeadersCopier","Get","Head","Post","PostForm","shouldCopyHeaderOnRedirect"],"path":"net/http"}]},"database_specific":{"source":"https://vuln.go.dev/ID/GO-2025-3420.json"}}],"schema_version":"1.6.0","credits":[{"name":"Kyle Seely"}]}]}

PURL with std

curl -d @std.json https://api.osv.dev/v1/query

std.json

{ 
  "package": {
    "purl": "pkg:golang/std@1.23.4"
  }
}

Result

{}

It seems that CVE scanner does not recognize PURLs with std. Same feedback from the trivy devlopers. Thus scanning SBOMs with a PURL that contains "pkg:golang/std" will ignore CVEs.

Would you mind joining the discussion with the trivy developers?

[stevespringett]

toolchain also isn't a valid package.
https://pkg.go.dev/toolchain

Would you mind joining the discussion with the trivy developers?

I am not a Go developer. However, I can say that vulnerability management is just one of many use cases that CycloneDX provides. Trivvy on the other hand, that's their primary use case.

Simply changing std to stdlib will result in:

• Incorrect inventory
• Inability to identify current std version and other details (without ugly go-specific hacks)
• Inability to validate license information (again, without ugly go-specific hacks)
• Challenges for organizations that need to sign and attest to the accuracy of the BOM

But it would return return vulnerabilities because it appears the Go security team is incorrectly using the wrong package name, which is unfortunate. Again, I may be completely wrong here as I'm not a go developer, but on the surface, this appears to be the case.

@nscuro what are your thoughts?

[stevespringett]

Assuming my observations are correct, one potential thing that we could do without introducing defects into this library and without negatively impacting use cases other than vulnerability management, is to leverage the evidence support in the specification. An example of this can be found here: https://cyclonedx.org/use-cases/software-components/

This would mean that we could do something like this:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "std",
      "version": "1.23.4",
      "purl": "pkg:golang/std@1.23.4",
      "evidence": {
        "identity": [
          {
            "field": "purl",
            "confidence": 1,
            "concludedValue": "pkg:golang/std@1.23.4",
            "methods": [
              {
                "technique": "manifest-analysis",
                "confidence": 0.7,
                "value": "pkg:golang/std@1.23.4"
              },
              {
                "technique": "attestation",
                "confidence": 0.5,
                "value": "pkg:golang/stdlib@1.23.4"
              }
            ]
          }
        ],
      }
    }
  ]
}

In this example, the BOM is correcting asserting the identity of the component, but is also providing evidence of how the identity was obtained. Here, we're including an attestation that an alternative identity exists. Any consumption tool that supports identity evidence, would then be able to use these values for vulnerability management.