If you search for “How to Automate SBOM Creation” you’ll find a huge number of results. As a software engineer, I personally get frustrated by those results almost instantly. Instead of telling me how to automate the creation of my SBOM, most of them spend half the article telling me why I should automate my SBOM creation. Then the article might close with some select examples or concepts to consider while I’m working. I’m going to skip most of that, since I know you can find it easily enough. I did find one good article here, but I want to do this a bit differently by focusing just on tools you can actually use in your CI pipeline for free right now.
In this article, we’ll look at five different real-world tools that you can pull down and try as soon as you like. It doesn’t matter which of these you use, as long as you use something. Don’t procrastinate any longer… Just pick one, crack open the docs, and get started!
These tools produce either or both of the common SBOM formats: SPDX and CycloneDX. You’ll need to consider which is best for your use. In a future article, I will show you how to convert between the two, so don’t feel like you’re marrying one when you set up your tooling today.
1. CycloneDX Maven plugin
“The CycloneDX Maven plugin generates CycloneDX Software Bill of Materials (SBOM) containing the aggregate of all direct and transitive dependencies of a project. CycloneDX is a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis.”
Java only. This plugin can create SBOMS for modules, packages, or be run against the root of a project to create the bill of materials for everything it finds. The documentation is well organized and will get you started in seconds.
Bonus: If you’re pushing to Maven Central, you can compare your SBOM to the dependency analysis provided by Sonatype on your public page. There’s also a Sonatype Safety Rating that will help triage your next steps to securing the supply chain for your Java project.
2. Kubernetes bom
“bom is a utility that lets you create, view and transform Software Bills of Materials (SBOMs). bom was created as part of the project to create an SBOM for the Kubernetes project. It enables software authors to generate an SBOM for their projects in a simple, yet powerful way.”
Works for container image dependencies too! Best for Go applications. If your local repository has licenses, they will be processed into SPDX as well. If your project is built with Go, then the dependencies will be processed.
Bonus: The Cilium build pipeline includes an example of signing the SBOM image in their automation, which you should definitely consider doing as well.
3. Microsoft’s SBOM tool
“The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 compatible SBOMs for any variety of artifacts.”
Yes, it works with Linux and Mac, not just Windows. Comes ready with a Dockerfile for you to maintain your own image. Comes with a quickstart guide for both GitHub Actions and Azure DevOps Pipelines!
4. SPDX SBOM generator
“spdx-sbom-generator tool to help those in the community that want to generate SPDX Software Bill of Materials (SBOMs) with current package managers. It has a command line Interface (CLI) that lets you generate SBOM information, including components, licenses, copyrights, and security references of your software using SPDX v2.2 specification and aligning with the current known minimum elements from NTIA. It automatically determines which package managers or build systems are actually being used by the software.”
Works for a variety of languages (see their documentation). Can be run by pulling the source code and executing it directly, or by running their Docker image (better for CI purposes).
“A CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems.”
Provides your choice of SPDX or CycloneDX. Works with a wide variety of languages (see the documentation for a full list). A GitHub Action is available to streamline the process for you if that’s your CI/CD platform of choice.
Bonus: You should ALWAYS pin ALL dependencies to a hash, instead of just pinning a version number. The hash will never change, while the version pointer is able to be modified to point to a different point in the code history. Check out how Kube VIP did it in their pipeline when using the Syft GitHub Action to automate their SBOM creation.
Final bonus topic: SBOM analysis
Since we’re already talking about automating your SBOM creation, I figure you probably want to actually use that SBOM for something. When I’m writing software (or at least when I’m responsibly writing software), I need to understand my dependencies, and their dependencies, and so on. Understanding my direct AND transitive dependencies would be a dream, but the work required to do that has always been a nightmare. If you’re in application security, you probably actually had to live that nightmare on multiple occasions. Fortunately, the winds of change are upon us.
Last year, when Sonatype mobilized its security researchers and machine learning techniques to create the 2022 State of the Software Supply Chain, we realized that there was a huge gap in this area, which the greater software community has increasingly begun to fill.
You can explore the awesome-sbom GitHub repository, a curated list of SBOM-related tools and resources. This repository offers a wide range of tools to help you analyze your SBOM effectively, ensuring that you make informed decisions about which dependencies to include and when to upgrade or remove them.
An SBOM is a great tool for AppDev and AppSec if you use it to make informed decisions of which dependencies to include and when to upgrade (or remove) them.
This is the end of your lecture on “Don’t just create the SBOM… actually use it!” You now have zero excuses left! Go set up your pipeline to generate a software bill of materials, and then use the data you gained to start improving your security posture.