What is an SBOM? SBOM explained in 5 minutes

SBOM stands for Software Bill Of Materials: a nested description of software artifact components and metadata. This information can also include licensing information, persistent references, and other auxiliary information.

The practicality of providing a list of contents within a package can be found everywhere. For example, are you familiar with E numbers? These are codes for substances used as food additives.

Listing E numbers (E stands for Europe) in food labels is mandatory within the European Union and European Free Trade Association. As some substances are safe and others are harmful, sorting them enables a conventional way to describe the ingredients of a food product so that consumers can judge whether or not they want to purchase them.

For practical reasons, it would be quite useful if software products had a similar mechanism for sorting good and bad ingredients so users can determine if they are safe or harmful. Enter the SBOM.

History

Back in 2009~2010, two standards emerged. Those leading SBOM formats are SPDX and SWID; both comply with NIST’s specifications laid out following the US Executive Order of May 2021.

• SPDX®: The Software Package Data Exchange®
  Originally, a standard focused on licensing, with SPDX License List still being the de-facto standard for licensing references and matching.
• SWID: Software Identification Tags
  A structured metadata format for describing a software product, including its phase in the software deployment life cycle.

In 2014, the Cyber Supply Chain Management and Transparency Act of 2014 (H.R.5793) was introduced in The House of Representatives of the US Congress. The legislation did not pass - but it drew attention to SBOM and the importance of transparency in the supply chain of software products.

In 2017, OWASP entered the arena by introducing CycloneDX: a security-centric SBOM format and a set of tools to generate and use it.

In 2021 the world faced a trend of cyber-attacks on supply chains, with vulnerabilities like Log4Shell having a worldwide impact on all industries relying on software. Acknowledging the lack of preparation, the Biden administration issued the Executive Order on Improving the Nation’s Cybersecurity of May 2021, which ordered NIST to define a set of standards for software delivery for the US Federal government:

The private sector must adapt to the continuously changing threat environment, ensure its products are built and operate securely, and partner with the Federal Government to foster a more secure cyberspace.  In the end, the 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.

…

(e)  Within 90 days of publication of the preliminary guidelines pursuant to subsection (c) of this section, the Secretary of Commerce acting through the Director of NIST, in consultation with the heads of such agencies as the Director of NIST deems appropriate, shall issue guidance identifying practices that enhance the security of the software supply chain.  Such guidance may incorporate the guidelines published pursuant to subsections (c) and (i) of this section.  Such guidance shall include standards, procedures, or criteria regarding:

…

(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
…

(f)  Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM.

Finally, on February 2022, NIST published Secure Software Development Framework (SSDF) Version 1.1, describing recommendations for mitigating the risk of software vulnerabilities”, including:

PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).

Following that publication, The White House published a statement on March 07, 2022, clarifying that the SSDF recommendations must be adopted by Federal agencies effective immediately:

The EO also directs the Office of Management and Budget (OMB), within 30 days of the issuance of the SSDF, to “take appropriate steps to require that agencies comply with such guidelines with respect to software procured after the date of this order.”  As such, Federal agencies must begin to adopt the SSDF and related guidance effective immediately, tailoring it to the agency’s risk profile and mission.

SBOM Life Cycle

First, there’s code. Your app could be comprised of an npm project, Python scripts, Go modules, or maybe a combination of technologies. Sooner or later, your code goes through the CI/CD pipeline, and if nothing breaks, you get an artifact at the end.

Your artifact might be a container, a tarball, or a package. Essentially, it is a file or a file system packed one way or another.

Now that we have the inputs for the SBOM, we can generate an SBOM and associate it with the artifact.

Finally, you can use the SBOM for your needs - sign it, serve your customers, check for vulnerabilities and licenses, etc.

SBOM Anatomy

Although there is not a single definitive standard for SBOM, NTIA did define the minimal requirements.

An SBOM must describe the supplier of the software and the author of the SBOM:

• The organization/person that created the artifact.
• The tool used to generate the SBOM.
• The timestamp when the SBOM was generated.

In addition, the SBOM must contain a complete description of the artifact components, including:

• Component name.
• Component version.
• A unique identifier (e.g., CPE / PURL / SWID).
• Relationship with other components.

Any extra static component information, i.e. information on the component that does not change in time, might be added to the SBOM as well. That information might include licensing, repository information, description, owner, etc.

Formats

The minimal requirement states 3 supported SBOM formats: SPDX, CycloneDX and SWID.

While SWID can serve as an SBOM, it is not as popular format as the others for representation of modern SBOMs, and is not supported by most common open-source SBOM tools.

SPDX sample

SPDX sample

An SBOM representing a very simple Go application generated by opensbom-generator/spdx-sbom-generator:

Compliance - Practices & Process Requirements

In addition to the content and the format of SBOMs, the NIST paper describes the practices and processes that organizations need to follow when supplying SBOMs:

• Frequency: SBOMs must be updated per any change in content or version of the software product.
• Depth: The SBOM must contain all direct and indirect dependencies of the software product.
• Known Unknowns: In any case that a piece of information is missing, the SBOM must state whether that information is missing because it is unavailable, unknown, etc.
• Distribution & Delivery: The SBOM must be accessible to the customer by means of being both machine- and human-readable.
• Access Control: Proper access control must be set to access the SBOM.
• Accommodation of Mistakes: All users of SBOM must acknowledge that the standards are still in development and be patient with mistakes in the process and substantial changes to the standard.

What can SBOM do for you?

SBOM technologies are still in development, but you can already take advantage of SBOM tools to improve your SDLC:

Observability, Dependency Tracking, and Coverage

• Incident Response: Easily find all affected components In any case of incident (e.g. Log4Shell).
• Due diligence & High Assurance: Instantly provide a comprehensive description of your software product, including its components, licensing information, dependencies, etc.
• Migration and Modernization: View the set of components from which your product is comprised and plan accordingly.
• Research & Improvement: Leverage the knowledge to research your product, find pitfalls, and track your organization's progress.

Security

• Vulnerability Scanning: Automatically scan your 3rd-party dependencies for vulnerabilities.
• Cryptographic-Signed SBOMs: Sign your SBOMs to provide a trusted description of your product contents.
• VEX (vulnerability exploitability exchange): Use SBOMs to produce and deliver VEX documents - documents that aim to provide users additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.
• Zero Knowledge Verification: Share your SBOM to rely on 3rd-party service to scan vulnerabilities, license info, etc., without letting your source code leave your safe and secure data center.

Legal & Compliance

• License Tracking: Track the licenses your product relies on and enforce policies to prevent misuse of protected intellectual property.
• US Executive Order: Comply to the US Executive Order in order to sell software to the US government.
• SLSA (Supply chain Levels for Software Artifacts): Enable SLSA level 4 by producing SBOMs that adhere to SLSA’s provenance requirement of Dependencies Complete

Where SBOM is going next

The different SBOM standards are still in development, with SPDX 3.0 being drafted and CycloneDX being updated continuously. The new SPDX standard should allow SBOMs to store more information, such as security information (e.g. VEX), better component relationships and dataflow descriptions, and possibly even provenance information.

Open-source projects are expected to improve and expand: projects like Syft will support more input (package) types, produce SBOMs with more depth and complicated relationships, and will integrate more features into it (e.g., Grype).

SBOM is still in its early adoption phase, but all surveys predict a rise in both its generation and consumption. As adoption rates rise, we expect to see SBOMs integrated as a standard format into more registries, services, and APIs.

Going Beyond SBOMs

SBOMs are a very practical idea and the time has come for broader adoption. However, SBOMs are just one aspect of the visibility that organizations need across their software supply chain in order to ensure it is secure. 

Contact Legit Security if you'd like to learn more about SBOMs and how you can go beyond SBOMs to gain greater visibility and security across your entire software supply chain environment. To learn more best practices in software supply chain security, check out our guide: Best Practices to Secure Your Software Supply Chains.