Get started with Software Bills of Materials
SBOMs tell you exactly what’s “inside” a particular “thing”
Prefer a hands-on demo?
As a companion to this article, here is a free hands-on demo to generate and audit your very first SBOM.
If I asked you to mail a package for me, your first question would likely be “what is inside?” In the software world, that’s the question a software bill of materials (SBOM) answers.
An SBOM tells you exactly what’s “inside” a particular “thing.”
This provides knowledge and provides answers to questions such as:
- What is in my box?
- What is in my box that shouldn’t be?
- What is making my box “heavy” that I could remove?
- What isn’t in my box that should be?
- Am I sufficiently qualified or licensed (e.g., “allowed”) to carry the things in this box?
Remember that each “thing” in the box might be a “set of other things.” If my hypothetical (and very large) box contained a vehicle, that vehicle would consist of multiple parts: the engine, the radio, the immobilizer system, and so on. The engine probably consists of more companies' bolts, filters, and screws.
Understanding this “tree” of dependencies is critical. If your car can be hacked via the radio, then the weakest component (radio) of the “whole” (car) can still compromise the car.
Why do I need an SBOM?
In May 2021, the US president issued an Executive Order: Improving the nation's cyber security. While this EO specifically targets US Federal governments and agencies, software of all shapes and sizes — from personal projects to enterprise software — is equally affected.
One part of the EO requests a review of SBOMs and the feasibility of making SBOM generation mandatory. To quote directly from the EO:
“An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software.
Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they're at potential risk of a newly discovered vulnerability.”
An SBOM can help:
- Improve software and security observability
- Identify and reduce supply chain risks
- Improve customer confidence
- Support regulatory compliance
What exactly is in an SBOM?
As directed by the President, the NTIA followed with a report and guidance on the minimal elements required inside an SBOM. This includes things like the supplier name (e.g., Ford), the component name (e.g., screw model T0), and the dependency information (e.g., this screw is part of the radio component).
How do I create an SBOM?
A Software Bill of Material can be created for any software. The most basic way would be a manually created list of all the “stuff” you know is in your code.
That works, to an extent, but is slow, error-prone, and thus doesn’t scale. Modern tools allow the generation of these lists automatically. Tools such as Microsoft’s open source SBOM Tool, Anchore’s Syft, and Kubernetes bom tool all generate SBOMs.
How do I audit an SBOM?
Having an SBOM is no use, of course, unless you do something with it.
- Step 1: Generate an SBOM
- Step 2: Audit the SBOM for known vulnerabilities and issues
The hands-on demo uses two OSS products from Anchore: Syft and Grype.
Limitations of SBOMs
Nothing in life is perfect, and SBOMs have limitations too.
List of components
It is important to realize that an SBOM is a static list of components. An SBOM is generated by someone or something. The file is unaware of where, when, or how those components are used. Of course, you also need to trust the author of the SBOM. If something is omitted from the list, it can’t be detected as vulnerable.
While an SBOM is static in one way: Re-scanning the same thing will always provide the same SBOM output. It is important to realize that an SBOM highly depends on the environment. Scanning a Dockerfile will give one result. Building and scanning an image built from that Dockerfile will give a different result. So it’s not a “one and done” process.
IT security research never stops, and GUAC (pronounced like the dip) is a new open source project from Google that aims to address some of the abovementioned areas.
What can I do now?
Adopting SBOMs is a great step to gaining observability into your environment and the things (potentially) running there.
Generate (and maintain) SBOMs for your software. Encourage software vendors you rely upon to create SBOMs so you can audit their software.
Start here with this free hands-on demo to generate and audit your first SBOM.