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.” -
https://github.com/CycloneDX/cyclonedx-maven-plugin
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.”
- https://github.com/kubernetes-sigs/bom
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.”
- https://github.com/microsoft/sbom-tool
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-generatortool 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.”
- https://github.com/opensbom-generator/spdx-sbom-generator
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).
5. Syft
“A CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems.”
- https://github.com/anchore/syft
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 Report, we realized that there was a huge gap in this area. Tools exist, sure… but the nightmare persisted even when using the tools on the market. In an effort to help raise the security standard of the entire software industry, Sonatype created BOM Doctor, a free tool that helps visualize the dependencies listed in an SBOM (Java only… for now). Just drop your file in, or point it at a repo with an SBOM, and it’ll create a visual graph that does helpful things like highlight the weakest link in every transitive chain.
If you aren’t working in Java and can’t take advantage of BOM Doctor yet, you can still learn from the approach. 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.
