Add an sbom workflow

[Amndeep7]

Explore sbom options

#6035 - can use the deploy preview here to visualize cyclonedx sboms

• GH export SBOM button
  Button on the dependency graph that needs to be manually clicked by a logged in person (who presumably has maintainership over the project?), produces what seems to be high quality spdx output, presumably only gives you the sbom for the current state of the default branch

  https://github.com/mitre/heimdall2/network/dependencies

  heimdall2_mitre_134f056cbf445867284713e2fe0eeb4ad40672bb.json

• GH sbom generator action

  Unmaintained action, seems to produce not high quality SPDX output only, errors out when trying to convert that SPDX output into CycloneDX format using cyclonedx-cli

  https://github.com/advanced-security/sbom-generator-action

  spdx-3dce7cb9-8f9a-422f-915c-17d53749621d.spdx.json

• GH sbom cli

  Maintained cli tool, available in the runner by default, need to install extension (that seems to only get intermittent maintenance) in order to hook into github sbom generation apis

  • SPDX
    spdx output seems to be high quality and more or less matches the output from the 'export sbom' button in the dependency graph ui, spdx output errors out when trying to convert it into cyclonedx
  • CycloneDX
    native cyclonedx times out i think due to using up all the allowed time trying to hit the graphql api

  https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md
  https://github.com/advanced-security/gh-sbom
  https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-github-cli-in-workflows
  https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits

  ghas_cli_sbom.spdx.json

• Anchore Syft action
  Maintained action, spdx output still throws errors when trying to convert into cyclone dx

  https://github.com/anchore/sbom-action

  • Directory - uninstalled deps

    • SPDX
      Relatively high quality, seems to provide a full listing of all of the ruby (inspecjs -> inspec-bin for use to update the schema) and npm dependencies, but doesn't list out the go dependencies that were brought in by esbuild, doesn't provide good cross-npm-library dependencies that it should still be able to generate from just the yarn.lock file (the '.' directory is just dependent on everything in there, but ex. doesn't show how all the AWS dependencies are connected)

    syft_directory.spdx.json

    • CycloneDX
      Just a component list that seems to contain the same components

    syft_directory.cdx.json

  • Directory - with installed deps
    More or less the same as above, except it seems to have discovered an additional 100 or so deps somehow.

    syft_directory_installed.spdx.json
    syft_directory_installed.cdx.json

    • use cyclonedx diff functionality to determine what the diff is between the two boms, specifically which deps were discovered
      The differences seem inconsequential. The following command .\cyclonedx-win-x64.exe diff --component-versions --output-format json '.\Syft SBOM experiments\syft_directory.cdx.json' '.\Syft SBOM experiments - just directory - installed\syft_directory_installed.cdx.json' > diff.json created a file that showcased that almost everything was unchanged though there were a few that had stuff in them but for some reason they seemed like they were primarily github action related but seemed to also have the esbuild stuff and some random other ones. You can use added": \[\n as an example search regex.

      diff.json

  • Image

    • SPDX
      Relatively high quality, provides the go (esbuild) and npm and operating system (rhel) dependencies but no ruby ones (which makes sense since we don't copy over any of the ruby package manager related stuff into the container), the operating system and go dependencies are properly linked up but the npm ones are not cross-connected properly even though presumably they ought to be since at least the backend's node_modules was brought in

    syft_image.spdx.json

    • CycloneDX
      Contains more or less the same info ^

    syft_image.cdx.json

• CycloneDX

• Microsoft SBOM-Tool
  Does not produce high quality SBOMs. 1) Generates v2.2 SPDX files only (as far as I can tell) whereas the current version of the spec is 2.3 on the 2.x branch and 3.0 on the latest version, 2) requires a workaround to have be converted via cyclone-dx cli (the bug seems to be on the cyclone dx side), 3) more specific info in the directory vs image discussions.

  https://github.com/microsoft/sbom-tool
  https://github.com/microsoft/sbom-tool/blob/main/docs/sbom-tool-arguments.md
  https://github.com/microsoft/sbom-tool/blob/main/docs/setting-up-github-actions.md
  https://learn.microsoft.com/en-us/azure/security/container-secure-supply-chain/articles/attach-sbom
  SBOM conversion issue. CycloneDX/cyclonedx-cli#385
  ExternalRefCategory 'PACKAGE_MANAGER' is not compliant with SPDX 2.2 specification CycloneDX/cyclonedx-dotnet-library#267

  • Directory
    It processes every single file in the directory that I pointed it at resulting in an absolutely insane number of results due to the .git and various node_modules directories. For the packages that it does find, it doesn't return any useful data aside from the name and package version. On top of that, it actually skips a considerable amount of packages according to the output from the terminal and doesn't find any of the relationships.

    directory.cdx.json.zip
    manifest.spdx.json.zip
    manifest_fixed.spdx.json.zip

  • Image
    Same as above but it only found a couple hundred linux packages.

    image.zip

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud