MMS • Sergio De Simone
Article originally posted on InfoQ. Visit InfoQ
GitHub has announced a new SBOM export feature meant to be used as part of security compliance workflows and tools. The new feature allows you to export NTIA-compliant SBOM easily, says GitHub.
Users can export SBOMs in a number of different ways, either manually or through an automated process. To generate the SBOM manually, you visit the dependency graph of your repository and click the new Export SBOM button.This will create a machine-readable SBOM in the SPDX format.
SPDX, short for Software Package Data Exchange is an open format specifically defined to describe a software bill of materials, including any dependencies, licenses, copyrights, and security references. There exist many tools, both commercial and open-source, that can be used to consume SPDX files to validate, analyze, or convert them to other formats.
Besides using the GitHub Web UI, it is also possible to export SBOMs using a GitHub CLI’s extension or a GitHub Action.
The GitHub CLI extension can be installed by running gh ext install advanced-security/gh-sbom
. After that, gh sbom -l
will output the SBOM in SPDX format, while gh sbom -l -c
will use the CycloneDX format.
As an alternative to the GitHub CLI, a GitHub action can be used to export SBOMs at build time. GitHub provides its own GitHub Action to export an SBOM from a dependency graph. If you prefer it, you can use Microsoft sbom-tool, or Anchore SBOM Action, which is based on Syft.
In future, the company says, exporting SBOMs will also be possible through a specific REST API.
An additional possibility offered by GitHub is uploading an existing SBOM to a repository to generate a dependency graph. This can be useful to organizations that prefer not disclosing all the dependencies they are using in their software. Once a dependency graph is generated, it becomes possible to receive Dependabot alerts for any vulnerability discovered in the repository or any of its dependencies.
It is important to understand that an SBOM, while required in many industries and at the US government level, is only one of many tools that can be used to protect a software supply chain. It will not solve by itself the problem of a dependency being potentially compromised, but it will help you better gauge the security risk associated by your implementation choices and understand who you are trusting, recursively, by including a given dependency into your system.