As we expand our portfolio of open source SBOM tools, we are excited to announce the release of sbom-action, a GitHub Action for creating a software bill of materials (SBOM) using Syft.
The sbom-action
is a simple way to generate a software bill of materials (SBOM) in your GitHub-based workflows and releases.
Why generate an SBOM, you ask? Because that’s what all the cool kids are doing! That, and supply chain security is increasingly important for software vendors. Many developers are already aware of the Executive Order on Improving the Nation’s Cybersecurity, its emphasis on securing the software supply chain, and the requirement for SBOMs in particular. Combine that with recent, headline-making attacks like SolarWinds and Codecov and DevOps teams are taking notice, making SBOMs a required part of the development lifecycle.
The first step in securing your supply chain is to create an inventory of the software and libraries being used during your build and deployment cycle. This is where the sbom-action comes into play. Under the hood, the sbom-action uses the open source tool Syft to provide container image and directory-based SBOM generation, which makes it easy to add multiple SBOM-generation steps to your workflows. Among other things, this can be used to track build-time dependencies that may not be easily determined in the final product.
Every software project is different, but you should be able to identify the components used during the build and deployment cycles and how they are used. It can be important to generate SBOMs at multiple stages in the development process. Security risks that are introduced in various stages of the development and build process may not be easily detectable once the container image is fully built.
Take, for example, a common type of project that uses NPM packages but builds a bundle that ultimately gets distributed in a container with a minimal web server. An example of this type of project can be seen here. During build time, a malicious package could be introduced. Without a record, or SBOM, to identify and track what software was added along the way, you would have no way of knowing if that malicious code made it into the resulting container or at what stage in the cycle it was added.
Using the sbom-action
is as simple as just adding a step to your GitHub Actions workflow. Using the aforementioned example, let’s say your repository contains a NPM-based project that builds a React App locally and copies the files to a static web server container. You may have a workflow set up which does something like this:
- run: npm install
- run: npm run build
- run: docker build -t my/image .
In order to generate the most accurate SBOM, you would add another step after npm run install
but before docker build
. In this case, all you need to do is add one step that uses: anchore/sbom-action
:
- run: npm install
- uses: anchore/sbom-action@v0
- run: npm run build
- run: docker build -t my/image .
The sbom-action
will automatically run in the workspace root and attempt to find all dependencies based on the NPM or Yarn lockfiles, generate an SBOM and upload it as a workflow artifact, and finally, detect if the sbom-action
was run during a GitHub release and automatically upload the SBOM as a release asset.
Then, to scan the container, just add another step with the image parameter:
- uses: anchore/sbom-action@v0
with:
image: my/image
With multiple options for scanning and configuration, sbom-action
can easily be used to generate SBOMs from both simple and complex scenarios.
Generating SBOMs and using them to track components through the development cycle is quickly becoming an integral part of securing the software supply chain and sbom-action provides an easy way to make this part of your GitHub Actions workflows.
Future sbom-action
enhancements include:
Go here to start using sbom-action
today! Let us know what you think and consider giving it a star on GitHub to show your support!