A “Software Bill of Materials” (SBOM) is effectively a nested inventory, a list of ingredients that make up software components. The following documents were drafted by stakeholders in an open and transparent process to address transparency around software components, and were approved by a consensus of participating stakeholders.
Introduction to SBOM
SBOM at a Glance is an introduction to the practice of SBOM, supporting literature, and the pivotal role SBOMs play in providing much-needed transparency for the software supply chain. (Japanese translation)
The FAQ document outlines detailed information, benefits, and commonly asked questions.
The Two-Page overview provides high-level information on SBOM’s background and eco-wide solution, the NTIA process, and an example of an SBOM.
This playbook outlines workflows for the production of Software Bills of Materials (SBOM) and their provision by software suppliers, including software vendors supplying a commercial product, contract software developers supplying a software deliverable to clients, and open source software (OSS) development projects making their capabilities publicly available.
This playbook outlines workflows for the acquisition, management, and use of SBOM by software consumers, including commercial and non-commercial entities acquiring third-party software capabilities from a supplier.
This document is intended to help the reader to understand and dispel common, often sincere myths and misconceptions about SBOM.
A collection of initiatives, guidance, models, frameworks, and reports that explicitly or implicitly highlight the value of SBOM.
This is the Second Edition of this resource, which serves as a detailed introduction to SBOM. It defines SBOM concepts and related terms, offers an updated baseline of how software components are to be represented, and discusses the processes around SBOM creation.
Instructions and guidance on how to generate an SBOM based on the experiences of the Healthcare Proof-of-Concept working group.
Phase II confirmed the value of providing SBOM information, proving the viability of the baseline elements, expanding use cases and participants, developing a how-to guide, and exploring the use of VEX.
This resource offers a brief introduction to VEX, which allows a software supplier to clarify whether a specific vulnerability actually affects a product.
This resource frames the dimensions of SBOM creation and delivery, to support more consistent and effective articulation of needs between requesters and suppliers of SBOMs.
This resource reviews the challenges of identifying software components for SBOM implementation with sufficient discoverability and uniqueness. It offers guidance to functionally identify software components in the short term and converge multiple existing identification systems in the near future.
This resource offers a categorization of different types of SBOM tools. It can help tool creators and vendors to easily classify their work, and can help those who need SBOM tools understand what is available.
This resource describes how SBOM data can flow down the supply chain, and provides a small set of SBOM discovery and access options to support flexibility while minimizing the burden of implementation.
Resources, Research, & Reports
The following documents, drafted and approved in 2019, provide guidance on what an SBOM is and how it can be used, and a practical case study from the healthcare sector.
This resource defines SBOM concepts and related terms, offers a baseline of how software components are to be represented, and discusses the processes around SBOM creation. With terminology and a background of the NTIA process, it serves as a detailed introduction to SBOM.
This resource summarizes the benefits of having an SBOM from the perspective of those who make software, those who choose or buy software, and those who operate it. It characterizes the security, quality, efficiency, and other organizational benefits, as well as the potential for the broader ecosystem across the supply chain.
This resource summarizes existing standards, formats, and initiatives as they apply to identifying the external components and shared libraries used in the construction of software products for SBOMs, highlighting three key formats of SPDX, CycloneDX, and SWID. The group analyzed efforts already underway by other groups related to communicating this information in a machine-readable manner.
This resource documents the successful execution and lessons learned of a proof-of-concept exercise led by medical device manufacturers (MDMs) and healthcare delivery organizations (HDOs). The exercise examined the feasibility of SBOMs being generated by MDMs and used by HDOs as part of operational and risk management approaches to medical devices at their hospitals.
For more information, please contact firstname.lastname@example.org
For upcoming and archived meeting details, please visit the NTIA Software Component Transparency page.