SBOM workflow using "npm sbom"

[martinkuba]

Which problem is this PR solving?

This replaces #4479

This workflow is using the npm sbom command to generate multiple SBOM files: one for each package and one for the whole repository (opentelemetry-js.spdx). All files are combined in a single zip file. The workflow is triggered when a release is published.

NOTE: The npm sbom command makes it possible to exclude dev dependencies (--omit dev configuration). However, there seems to be a bug where sometimes dependencies are not captured (see npm/cli#7204 for more details). Once the npm issue is resolved, the --omit dev configuration should be added to the commands in this workflow).

An example output from this workflow is available here.

[codecov]

Codecov Report

Merging #4521 (ea28153) into main (3a426e8) will increase coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4521      +/-   ##
==========================================
+ Coverage   92.83%   92.84%   +0.01%     
==========================================
  Files         328      328              
  Lines        9486     9486              
  Branches     2035     2035              
==========================================
+ Hits         8806     8807       +1     
+ Misses        680      679       -1     

see 1 file with indirect coverage changes

[trentm]

Looking, for example at part of opentelemetry-js_api.spdx:

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "opentelemetry@0.1.0",
  "documentNamespace": "http://spdx.org/spdxdocs/opentelemetry-0.1.0-b79ed234-0b6a-4cbd-8ccb-b280340bb394",
  "creationInfo": {
    "created": "2024-03-02T21:48:21.872Z",
    "creators": [
      "Tool: npm/cli-10.5.0"
    ]
  },
  "documentDescribes": [
    "SPDXRef-Package-opentelemetry-0.1.0"
  ],
  "packages": [
    {
      "name": "opentelemetry",
      "SPDXID": "SPDXRef-Package-opentelemetry-0.1.0",
      "versionInfo": "0.1.0",
      "packageFileName": "",
      "description": "OpenTelemetry is a distributed tracing and stats collection framework.",
      "primaryPackagePurpose": "LIBRARY",
      "downloadLocation": "NOASSERTION",
      "filesAnalyzed": false,
      "homepage": "https://github.com/open-telemetry/opentelemetry-js#readme",
      "licenseDeclared": "Apache-2.0",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/opentelemetry@0.1.0"
        }
      ]
    },
    {
      "name": "@opentelemetry/api",
      "SPDXID": "SPDXRef-Package-opentelemetry.api-1.8.0",
      "versionInfo": "1.8.0",
      "packageFileName": "node_modules/@opentelemetry/api",
      "description": "Public API for OpenTelemetry",
      "downloadLocation": "NOASSERTION",
      "filesAnalyzed": false,
      "homepage": "https://github.com/open-telemetry/opentelemetry-js/tree/main/api",
      "licenseDeclared": "Apache-2.0",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/%40opentelemetry/api@1.8.0"
        }
      ]
    },

Is it misleading that it references an opentelemetry@0.1.0 package? There actually is (perhaps by accident?) such a package published to npm: https://www.npmjs.com/package/opentelemetry?activeTab=versions
(That package is not malicious, BTW. It just contains a small package.json and useless one-line "index.js".)

Would setting "private": true in the top-level package.json change something here?

Perhaps all of this is fine. I don't have any experience with real use cases for SBOM files.

[trentm]

@martinkuba I guess you don't need final review until this is adjusted somehow to add this asset to the relevant GitHub Release?

I searched a bit for a way to do that and while there is a github.com provided "actions/upload-release-asset", it is unmaintained: https://github.com/actions/upload-release-asset
Basically it just calls the "upload-a-release-asset" GH API:
https://github.com/actions/upload-release-asset/blob/main/src/upload-release-asset.js#L22-L30

[martinkuba]

@martinkuba I guess you don't need final review until this is adjusted somehow to add this asset to the relevant GitHub Release?

@trentm @pichlermarc Trent is correct that we would need an extra step in the workflow to add the artifact to a release. This brings up a question whether it should be attached to the API and experimental releases as well. And if yes, should we have different workflows for the core SDK, the API, and experimental packages? I think the answer is probably yes, and I can split this into three different workflows (or conditional steps). What do you think?

[martinkuba]

Is it misleading that it references an opentelemetry@0.1.0 package? There actually is (perhaps by accident?) such a package published to npm: npmjs.com/package/opentelemetry?activeTab=versions (That package is not malicious, BTW. It just contains a small package.json and useless one-line "index.js".)

I tried with "private": true and did not make a difference. The version 0.1.0 is in the top-level package.json, so it is technically correct. Per the documentation of the field, the important part is that the value is unique for each file, which it is since it gets a unique UUID appended. In any case, the npm sbom does not have a way to customize it.

[martinkuba]

I have made the following updates

• added .json file extension to the generated SBOM files
• removed the SBOM file for the whole repository
• SBOM files are generated conditionally for core packages, experimental packages, or API based on the release tag
• the SBOM zip file is added to the release automatically as an artifact

[trentm]

LGTM.

[pichlermarc]

Looks good, thanks 🙂