Software Bill of Materials (SBOM) in Practice

On May 12, 2021, U.S. President Joe Biden issued the Executive Order on Improving the Nation’s Cybersecurity.  (Executive Order 14028)  A key piece of this order, and one that has garnered much attention in the FW/BIOS industry, is the requirement for a Software Bill of Materials (SBOM).  The Order defines this as:

(j)  the term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software.  Software developers and vendors often create products by assembling existing open source and commercial software components.  The SBOM enumerates these components in a product.  It is analogous to a list of ingredients on food packaging.  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 are at potential risk of a newly discovered vulnerability.   A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration.  The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems.  Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.

The Order defines "software" in the SBOM to include firmware and operating systems, so the BIOS community has busy working on what this means for implementations of BIOS.

What is an SBOM Anyway?

Progress has already been made on SBOM in UEFI.  So as not to repeat the great work that's already been done, let me direct you to a couple of good resources:

Traceable Firmware Bill of Materials Overview

Amy Nelson, Jiewen Yao, and Vincent Zimmer

UEFI Support for Software Bill of Materials (SBOM)

Felix Polyudov and Brian Mullen

SBOM in Practice

Since the aforementioned resources already do a good job introducing SBOM, my goal for this article is to experiment with SBOM more practically:  by actually using some available tools to build an SBOM and see what we get.

The SBOM community has identified three existing data standards (formats) that can convey the data needed to represent an SBOM: SPDX, CycloneDX, and SWID tags.

Experts in these formats have mapped between them to create interoperability for an SBOM baseline. Because these formats are already subject to public input and translation tools do exist, they serve as logical starting points for sharing basic data.

EMBA and CycloneDX

The first step is to download, install, and run EMBA.  EMBA is a multi-purpose security analyzer for firmware, including SBOM scanning and generation.  Installation is a simple and straightforward process, but be warned that it does take quite some time, maybe 40 minutes or more in my experience.

1. git clone https://github.com/e-m-b-a/emba.git
2. cd emba
3. sudo ./installer.sh -d

Once that is complete, as an experiment, I ran EMBA on EDK2's UEFI Shell like:

sudo ./emba -l ~/log -f ~/emba/shell.efi -p ./scan-profiles/default-scan.emba

(note: there is another scan profile called sbom-default.emba, but the default-scan.emba is a superset, and so also runs the SBOM portion of the test)

Once EMBA was complete I got lots of neat information, here's a sampling:

However, what was NOT present was an actual SBOM.  The log says:

[[0;34m+[0m] [0;36m[1mCycloneDX SBOM converter[0m

[1m=================================================================[0m

[[0;31m-[0m] Fri Jul  7 21:27:51 CDT 2023 - F21_cyclonedx_sbom nothing reported

So, my take-away here is that the shell.efi binary being examined does not contain the necessary metadata required for the EMBA tool to create a CycloneDX-style SBOM.

Undeterred, I attempted to run the same EMBA scan on a Coreboot BIOS image for the Lenovo T530 system.  There is a project called Skulls that contains pre-built Coreboot BIOS images, more here:  https://github.com/merge/skulls.  Some progress:

Now we're getting somewhere!  Pretty neat!

SWID Tags

The NIST web page for SWID Tag tools is:  https://pages.nist.gov/swid-tools/.  These are great for incorporating SBOM data into your build process, but they do not have the ability to scan pre-built firmware images, which is what I was looking to try out here.  Also, they are Java-based, which is not helpful for BIOS folk.

More promising is python-uswid:  https://github.com/hughsie/python-uswid.  This tool is:

• specific to EFI firmware
• Python-based, therefore compatible with EDK2
• maintained by Richard Hughes, creator of LVFS/fwupd and all-around great guy

So, while not a tool for scanning pre-built firmware images, this looks like promising scaffolding for integrating into a EDK2 build process to embed SBOM data into firmware images.

SPDX SBOM Generator

On the SPDX side of things, I did locate a good tool, but it is not specific to firmware:

SPDX Software Bill of Materials (SBOM) Generator

This might be a good option, but requires further analysis of how, if possible, to incorporate it into an EDK2-style build process.

Takeaway

Suffice it to say that SBOM generation is still immature.  My takeaway at this point in time is that the industry is still sorting out how best to satisfy the need for an SBOM.  Questions still being debated:

• do we put the SBOM in the binary, or put the SBOM reference in the binary?
• what data fields to include?
• how deep through the dependency tree should we go, and what if information is missing from a deeply nested dependency?

We'll have to keep our eyes on this space to see how things develop from here on out, but hopefully this article demonstrated how some existing tools might be used to create SBOMs.