Introduction to Software Bills of Materials (SBOMs) #
A Software Bill of Materials (SBOM) is a manifest which uniquely identifies and enumerates the software dependencies contained within a codebase, build artifact, or runtime container. A dynamic SBOM can further integrate information from vulnerability scanners to help ensure the integrity of your software supply chain.
What is motivating the need for SBOMs? #
To quote President Biden’s Executive Order 14028 on Improving the Nation’s Cybersecurity:
[T]he trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is, and to the consequences we will incur if that trust is misplaced.
This order calls for transparency in the software supply chain, and SBOMs are a key part of that transparency. Notably, the policies laid out in this order will require vendors to provide SBOMs for all software they sell to the federal government, which will result in more vendors requesting SBOMs from their upstream suppliers.
The tooling and standards for SBOMs are continuing to mature, and as it becomes increasingly important for developers of both proprietary and open source software to generate SBOMs for their projects, the integration of SBOMs into software development workflows will become more widespread. A pilot program created by the above order shows the potential for how SBOMs can be used to communicate the security posture of software products (emphasis added):
[The executive order] creates a pilot program to create an “energy star” type of label so the government – and the public at large – can quickly determine whether software was developed securely. Too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit. This is a long-standing, well-known problem, but for too long we have kicked the can down the road. We need to use the purchasing power of the Federal Government to drive the market to build security into all software from the ground up.
What is contained in a Software Bill of Materials? #
Generally speaking, an SBOM is a nested inventory of uniquely-identified dependencies.
From the NTIA’s SBOM FAQ (pdf) answer about what should be included in an SBOM:
An SBOM should contain some combination of the following baseline information: author name, supplier name, component name, version string, component hash, unique identifier, and relationship. Licensing, pedigree, provenance, should also be included, if available.
When an SBOM is generated by a tool such as Codenotary’s cas CLI, the complete inventory of included software components is generated locally—using the dependency trees assembled by build tools and package managers.
Assembled SBOMs can be shared between projects through interchange formats such as SPDX. That specification provides a common data format for sharing information about the provenance, licenses, and security information associated with a given component.
Other variants of SBOMs have appeared alongside the full SPDX specification, such as SPDX Lite, a subset of the full specification, and CycloneDX, a lightweight standard designed for application security contexts.
How is it used? #
Because an SBOM is fundamentally a metadata file meant to inventory components in use, a straightforward use case for these manifests is in determining what software is running where. When new vulnerabilities emerge (e.g. the log4j vulnerability), an inventory of all software components running on your infrastructure enables removal of these threats. When an SBOM is included in a dynamic, searchable SBOM database, developers can quickly find specific dependencies within their production assets.
From a security perspective, SBOMs increase transparency of the software supply chain and allow projects to avoid including dependencies with known vulnerabilities. When build artifacts are scanned for components with known vulnerabilities while in the build pipeline—long before the those vulnerabilities ever reach your production environment—the risk of releasing known-dangerous components is reduced.
When using CAS, notarized assets can be marked as Unsupported, and you configure the cas CLI to exit with an error when those unsupported dependencies are encountered. In addition to the security benefits of notarized SBOMs, uniquely-identified assets being marked as Unsupported helps keep outdated components from being deployed.
Enriched SBOMs like those from Codenotary Trustcenter track metadata about runtime environments (in addition to component dependencies), such as which Docker images contain a given dependency, providing additional visibility into deployments.