SnykSecThe software bill of materials (SBOM) is quickly becoming an essential aspect of open source security and compliance. In this post, we'll delve into what SBOMs are, why they're necessary, and their role in open source security.
What are SBOMs?
A software Bill of Materials (SBOM) is a comprehensive inventory of all components used in a software product. They include all the necessary details about each component, such as their names, versions, and licensing information. SBOMs can be seen as the ingredients list for software, providing complete transparency into what makes up a software product.
Consider a simple Python project with various dependencies. A simplified example of an SBOM for this project might look like this:
[
{
"component_name": "numpy",
"version": "1.21.0",
"license": "BSD"
},
{
"component_name": "pandas",
"version": "1.3.0",
"license": "BSD"
}
]
Why do we need SBOMs?
SBOMs serve a crucial role in understanding the composition of our software. But in the field of open source development, SBOMs play an even more vital role. Open source components often have their own dependencies, leading to a complex web of interconnected components. SBOMs help untangle this web, allowing us to understand the full scope of our exposure to potential security risks or compliance issues that come from third-party dependencies in our apps.
Delivering an SBOM alongside the created artifact is crucial because it enables whoever is using the software to asses the security status of the project. If a major vulnerability on a specific open source package is disclosed, like we have seen with Log4Shell and Spring4Shell, all consumers of the vulnerable components can now determine if this security vulnerability impacts them.
SBOMs are a valuable add-on to any piece of software that should be provided with every release. They provide transparency, enhance security and compliance, and contribute to higher-quality software.
Creating SBOMs with the Snyk CLI
Snyk’s command line interface (CLI) is an open source security tool that enables developers and DevOps professionals to find, fix, and monitor known vulnerabilities in open source dependencies. The Snyk CLI supports a broad range of programming languages and package managers — including JavaScript (npm, yarn), Python (pip), Java (Maven), .NET (NuGet), Ruby (RubyGems), PHP (Composer), and more. The Snyk CLI can be used locally or in a pipeline for SAST, SCA, container, and IaC scanning on a software project.
And now, it can also create SBOMs for your projects.
Installing the Snyk CLI
To get started with the Snyk CLI, you need to install it in your development environment. Below is a simple guide on how to install the Snyk CLI using npm. For more information or alternative ways to install the Snyk CLI, check out our user documentation.
npm install -g snyk
After installing the Snyk CLI, you need to authenticate your account using the snyk auth command. This will open a web browser for you to log in or sign up for a Snyk account.
snyk auth
Alternatively, you can set your Snyk token as an environment variable, which is the recommended way to use the CLI in a CI/CD pipeline. Check our handy CLI cheat sheet or the official documentation for more information.
Generate SBOMs using the Snyk CLI
Once the CLI is operational and connected to an enterprise Snyk account, it can start creating SBOMs for your software projects with the following command:
snyk sbom --format=
The --format option is required and specifies the output format for the SBOM to be produced. The choices are between CylconeDX, XML, or SPDX in JSON format.
You can save the SBOMs to the file by redirecting the stdout to a file using the > operator. For a simple project that needs a cyclonedx 1.4 JSON output, it looks like this:
snyk sbom --format=cyclonedx1.4+json > mysbom.json
Running this from the root directory of your project will give you an SBOM file that you can ship together with your artifact.
Alternatively, you can use the --json-file-output= flag to export SBOMs JSON output to a JSON file. This flag will obviously not work when you generate and XML variant of the SBOM.
Multiple projects
The Snyk CLI uses the package manifest file of your build system to determine the dependency tree and, therefore, the input of the SBOM. By default, the CLI stops after finding one manifest file. However, you may have more than one manifest file and more than one build system in your project. For example, you might have a project with a Java backend using Maven and a Node.js frontend using npm. By adding the --all-projects flag to the SBOM command, the Snyk CLI will traverse through your project looking for manifest files and add them to the result or your SBOM output.
snyk sbom --format=cyclonedx1.4+json --all-projects > mysbom.json
The default depth for searching for manifest files is four, this is configurable using the --detection-depth flag. In addition, it is also possible to exclude specific files with the --exclude flag.
snyk sbom --format=cyclonedx1.4+json --all-projects --detection-depth=3 --exclude=package.json > mysbom.json
Please be aware that there is a large number of command line flags available for specific ecosystems to handle — such as multi-module Maven files, configuration attributes in Gradle, Yarn workspaces, etc. For a full overview of all possible flags for Snyk SBOM, check our extensive documentation page.
Automating SBOM generation with the Snyk CLI
Automating software bill of materials generation with the Snyk CLI is a vital step for enhancing security and compliance in the CI/CD pipeline. By integrating the Snyk CLI into your build process, you can automatically generate a comprehensive SBOM each time your code is built. This SBOM lists all dependencies, including transitive dependencies.
As code moves through the CI/CD pipeline, Snyk can not only find security vulnerabilities but also ensure that an up-to-date SBOM is generated and delivered with every build release. This automation not only streamlines the process of maintaining a secure and up-to-date SBOM but also embeds security practices of your software development lifecycle, making it easier to comply with regulatory requirements and industry standards while building trust with your customers.
Analyzing SBOMs
Creating SBOMs is an effective and straightforward way to use the Snyk CLI. But what if you need to consume an SBOM and check if there are known vulnerabilities used in a software package? There are currently a few options available:
Snyk SBOM checker
Our Snyk SBOM security checker is an easy-to-use web interface.
Either drag or paste the CycloneDX or SPDX SBOM into the dedicated field and click on Check SBOM. Snyk will scan the provided SBOM and provide a list of vulnerabilities.
Bomber
Bomber is an open source application that scans SBOMs for security vulnerabilities. Snyk is one of the integrated providers in bomber to scan SBOMs.
To install bomber, download the latest release from the official GitHub repository, use Homebrew for macOS, or the dpkg tool for Linux.
Homebrew (macOS):
brew tap devops-kung-fu/homebrew-tap
brew install devops-kung-fu/homebrew-tap/bomber
Dpkg (Linux):
dpkg -i bomber_0.4.1_linux_arm64.deb
To run bomber from the command line with Snyk, you’ll need to provide a Snyk API token. You can retrieve this from the Snyk web interface. Otherwise, when the CLI is installed on your local machine, you can run snyk config get api
Once you have the Snyk API token, you can run bomber like this:
bomber scan --provider snyk --token xxx mysbom.json
The output will show you all known vulnerabilities on your screen.
Supplying up-to-date SBOMs with Snyk
The Snyk CLI can help you create up-to-date SBOMs for every build of your software. It’s good practice (and in some cases even required) to provide an SBOM with a built artifact to be compliant.
Using the Snyk CLI to automate SBOM production in your pipeline is a straightforward way to make this work. To wrap up, I’d like to recommend the following next steps for you when working with SBOMs in your projects:
