What is SBOM and why should we care?

If you've heard the term SBOM floating around, you may have wondered what it is, where it comes from, and how it impacts you in your software development work. We'll get into all of that, but let's start with a definition.

SBOM stands for Software Bill Of Materials, and the name builds on a term from the manufacturing industry. A Bill of Materials is a detailed list of all the physical components that make up the item being built.

For example, a Bill of Materials for a car would list everything built into the vehicle, from the big items like the seat cushions and steering wheel to the specific chips and microcontrollers built into the electronics of the engine.

In manufacturing, having this detailed list ensures that we know what components need to be available, how to assemble them, and what to do if there is a problem. This reduces risks faced in the manufacturing process and helps to ensure we can continue to produce items safely and efficiently.

If there’s a supply chain issue, such as a parts defect or shortage, this Bill of Materials allows manufacturers to identify the affected products quickly and take action.

The specifics of SBOM

An SBOM is an extension of this Bill of Materials concept, and it’s been applied to the developers (or manufacturers) of software since 2018.

An SBOM is an extensive, documented list that catalogs the components used in the development of a software product.

Given the rapid development processes and frequent changes made to software, there are five types of SBOM:

Design

SBOM of intended, planned software project or product with included components (some of which may not yet exist) for a new software artifact.

Source

SBOM created directly from the development environment, source files, and included dependencies used to build a product artifact. 

Build

SBOM generated as part of the process of building the software to create a releasable artifact (e.g., executable or package) from data such as source files, dependencies, built components, build process ephemeral data, and other SBOMs. 

Analyzed

SBOM generated through analysis of artifacts (e.g.,  executables, packages, containers, and virtual machine images) after its build. Such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “third-party” SBOM. 

Deployed

SBOM provides an inventory of software that is present on a system. This may be an assembly of other SBOMs that combines analysis of configuration options, and examination of execution behavior in a (potentially simulated) deployment environment. 

Source: https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf

As you can see, the process for creating an SBOM changes according to the maturity and/or stability of the product and the stage in the software development lifecycle.

New or pre-release products and features can produce preliminary or design SBOM that aim to communicate what the composition of the software might be once it is completed. This SBOM is indicative, not authoritative.

The further down the list you go, the more authoritative the SBOM becomes, even to the point of being analyzed and derived from third-party software. You may also hear this referred to as “software composition analysis”.

Why we need SBOMs and how they relate to application security

SBOM aims to help improve the security of our software supply chain, and that’s a good thing for all of us.  

Software supply chain security has become a high priority in the past three years. It centers around the idea that every piece of software has functional flaws and security flaws, and since our software is often tightly coupled together — through inheritance, packages, integrations, and cloud solutions — we can inherit risk from every piece of software and component we use.

Software supply chain security aims to understand where these software relationships exist and how they impact our security.

SBOM allows us to understand and articulate these connections in a simple, reusable format and share them with our customers and regulators.  

In the case of a security breach or vulnerability in a technology, we’re then able to identify which software would be impacted more easily and take appropriate steps to handle the situation.

SBOM: no longer a nice to have

As well as being a great tool in the fight to protect the security of the software supply chain, SBOMs are now becoming part of our regulatory and compliance environment.

The United States government is now requiring software manufacturers to produce SBOM, a requirement foreshadowed by President Biden in 2021 as part of an executive order, and now in the process of implementation and linking with existing security regimes such as FedRamp.

This government focus means that generating SBOM will be much more than a nice to have for mature organizations, but a fixed requirement for those doing business with state or federal government. We can expect this level of standard to spread globally over the next two years.

As this change and the related requirements roll out, it reinforces once again that security is not just a technical domain but an enabler to our businesses and that the changes we see come into place are positive developments all around.