Discoverability on the BOM Server

[captn3m0]

Creating this based on Discussion on Slack:

Quick question on SBOM retrieval via API. Is the assumption that a requestor already knows the SBOM URN? Are there plans to support URN identification by unique identifiers like PURL, CPE or SWID? Or is this left to implementer to determine? Completely understand there may be multiple SBOM for a given identifier.

We've discussed discoverability. Currently not specified. I'd recommend creating a ticket for the spec to support it.

Discoverability based on PURL/CPE will be very helpful for projects. It would also enable the creation of "public BOM servers", where one could host (say) SBOMs for every package on a specific distro or package manager.

Slack Ref: https://cyclonedx.slack.com/archives/C024GCLFJDR/p1652538141714249

[jkowalleck]

is this request in the correct repo? should it move to https://github.com/CycloneDX/cyclonedx-bom-repo-server ? or to https://github.com/CycloneDX/transparency-exchange-api ?

[captn3m0]

There's two standardization questions here:

1. URN identification via unique identifiers like PURL/CPE/SWID for a given SBOM.
2. Serving SBOMs via such identifiers on a server, one of which might be the bom-repo-server.

Till (1) is settled (ideally in the specification), I'm not sure if it can even be taken up by any SBOM server. As it stands, the SBOM metadata does not include a stable identifier for itself.

As a sample, this is what alpine:latest scanned via Syft shows up as:

{
  "$schema": "http://cyclonedx.org/schema/bom-1.4.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:16e4a07b-1174-4c6d-8783-f9d15c546924",
  "version": 1,
  "metadata": {
    "timestamp": "2023-07-27T10:12:21Z",
    "tools": [
      {
        "vendor": "anchore",
        "name": "syft",
        "version": "0.85.0"
      }
    ],
    "component": {
      "bom-ref": "5f08cdaf1f225f20",
      "type": "container",
      "name": "alpine:edge",
      "version": "sha256:12b034ab685c2031f14d2d99dff9db7049e05051c6dbce8905781d23c286b868"
    }
  },

Since this is a container image, which have unique PURLs, a discoverability mechanism would mean adding an identifier like:

pkg:docker/library/alpine@latest or pkg:docker/library/alpine@12b034ab685c2031f14d2d99dff9db7049e05051c6dbce8905781d23c286b868 inside the SBOM itself. Syft additionally adds a "operating-system" component at the end:

{
      "type": "operating-system",
      "name": "alpine",
      "version": "3.18_alpha20230329",
      "description": "Alpine Linux edge",
      "swid": {
        "tagId": "alpine",
        "name": "alpine",
        "version": "3.18_alpha20230329"
      },
      "externalReferences": [
        {
          "url": "https://gitlab.alpinelinux.org/alpine/aports/-/issues",
          "type": "issue-tracker"
        },
        {
          "url": "https://alpinelinux.org/",
          "type": "website"
        }
      ],
      "properties": [
        {
          "name": "syft:distro:id",
          "value": "alpine"
        },
        {
          "name": "syft:distro:prettyName",
          "value": "Alpine Linux edge"
        },
        {
          "name": "syft:distro:versionID",
          "value": "3.18_alpha20230329"
        }
      ]
    }

But this does not include a PURL (there is no PURL type for operating-systems), and is a description of the operating system inside the container image, its not a top-level identifier for what was scanned.

[stevespringett]

As it stands, the SBOM metadata does not include a stable identifier for itself.

The combination of serialNumber and version form the identity of the BOM. This identity can be expressed via BOM-Link. The BOM Exchange API currently supports this. There are plans to support discoverability based on the metadata>component via its purl, cpe, or swid.

[stevespringett]

Does Syft add:

"swid": {
  "tagId": "alpine",
  "name": "alpine",
  "version": "3.18_alpha20230329"
}

If so, that's so completely wrong. Nothing about that markup is correct.

[jkowalleck]

this topic might be related/referring to https://github.com/CycloneDX/transparency-exchange-api