A software bill of materials is an inventory of all software components (proprietary and open source), open source licenses, and dependencies in a given product. A software bill of materials (SBOM) provides visibility into the software supply chain and any license compliance, security, and quality risks that may exist.

SBOMs have become increasingly relevant and valuable in light of the fact that today's applications are generally built with many individual software components, often from a variety of open source and proprietary source packages. Given these complexities, it can be difficult for organizations and individuals involved with the product (manufacturers, operators, buyers) to have full visibility into the software supply chain and any license compliance, security, and quality risks that may exist.

By providing key insights in these areas, SBOMs help organizations quickly identify and remediate potential security vulnerabilities, fulfill licensing requirements, and apply version control best practices. Additionally, the Biden Administration's recent Cybersecurity Executive Order includes a provision that mandates SBOM creation (for organizations that sell into the federal government), further elevating their importance.

In this blog, we’ll explore a variety of topics related to a software bill of materials, including benefits, minimum required elements, and tools and templates to help create one.

Elements of a Software Bill of Materials

On July 12, 2021, the U.S. federal government published the minimum required elements of a software bill of materials (for the purposes of compliance with the Biden Administration's recent executive order). These guidelines apply only to organizations that conduct business with the federal government, but we wouldn't be surprised if organizations of all types adopt them sooner than later.

These minimum elements of an SBOM are grouped into three areas:

  • Data fields
  • Automation support
  • Practices and processes

We'll take a closer look at each of these elements in the sections below

Data Fields

The data field category includes information that describes the components that comprise a piece of software. Per the U.S. NTIA (National Telecommunications and Information Administration), the agency which published the SBOM minimum requirements, the intent of the data fields is as follows:

The goal of these fields is to enable sufficient identification of these components to track them across the software supply chain and map them to other beneficial sources of data, such as vulnerability databases or license databases.

They are:

  • Supplier Name
  • Component Name
  • Version of the Component
  • Other Unique Identifiers
  • Dependency Relationship
  • Author of SBOM Data
  • Timestamp

For additional context, "other unique identifiers" may refer to Software Identification (SWID) Tags, Package Uniform Resource Locators (PURL), Common Platform Enumeration (CPE), or other such identifiers. Also, “dependency relationship” means, essentially, how and where different software components fit together. Per the NTIA, it "enables the representation of transitivity from a piece of software to its component and a potential sub-component."

Automation Support

Organizations looking to closely and continuously track SBOM component data will need that data to be presented in consistent and digestible formats. The "Automation Support" section of the SBOM minimum requirements addresses this matter. It identifies three reporting formats that organizations must use when they transmit SBOMs across organizational boundaries. They are:

  • Software Package Data Exchange (SPDX)
  • CycloneDX
  • Software Identification (SWID) Tags

We will discuss these reporting formats in more detail later in this blog, but the NTIA selected them because each is human-readable, machine-readable, and "interoperable for the core data fields and use common data syntax representations."

Practices and Processes

Finally, the "Practices and Processes" section includes six requirements in areas related to how and when SBOMs should be updated and delivered. They are:

  • Frequency: New SBOMs must be created if the software component is updated with a new build or release.
  • Depth: SBOM authors should include both top-level components and their transitive dependencies.
  • Known Unknowns: In situations where the SBOM doesn't include a full dependency graph, the SBOM author should note whether this is because a) the component has no further dependencies, or b) the "presence of dependencies is unknown and incomplete."
  • Distribution and Delivery: SBOMs must be made available in a "timely" fashion — with "appropriate access permissions and roles in place."
  • Access Control: Organizations seeking to keep certain elements of a software bill of materials private are required to specify the terms of access control, "including specific allowances and accommodations for integrating SBOM data into the user’s security tools."
  • Accommodation of Mistakes: The regulations governing SBOM creation are obviously quite new, so SBOM consumers are directed to be tolerant of  (unintentional) errors or omissions.

READ MORE: SBOM Minimum Required Elements

Software Bill of Materials Delivery Formats and Specifications

Organizations can and do create and publish a software bill of materials in a number of different formats. HTML is a logical choice for a company seeking to publish the SBOM on its website. Plain Text might be the better option if the software bill of materials will be included in documentation or source code. And then there are options like Markdown, PDF, and CSV.

In addition to these common formats, there are several methods designed specifically for delivering SBOMs, including SPDX (Software Package Data Exchange), Software Identification (SWID) Tags, and Cyclone DX. As mentioned, organizations that sell into the U.S. federal government (and are consequently bound by the terms of the Biden Administration's Cybersecurity Executive Order) are required to convey SBOMs in one of these three formats.


SPDX, a project run by the Linux Foundation, aims to standardize the way organizations share and consume information found in a software bill of materials. SPDX captures data related to provenance, licensing, and security. The image below outlines what data can be found in an SPDX document.

A list of data that can be found in an SPDX document
Image via SPDX website


A Software Identification Tag (or “SWID” for short) is a standardized XML format that identifies and contextualizes the components of a software product. There are four types of SWID tags that come into play at different points in the software development lifecycle (SDLC)

  • Corpus Tags: These identify and describe software components in a pre-installation state. Per NIST, corpus tags are “intended to be used as inputs to software installation tools and processes.”
  • Primary Tags: The intent of a primary tag is to identify and contextualize software products post-installation.
  • Patch Tags: As the name implies, patch tags identify and describe the patch (as opposed to the core product itself). Additionally, patch tags can and do include contextual information on the relationship between the patch and other products or patches.
  • Supplemental Tags: The SWID format allows only tag creators to modify corpus, primary, and patch tags. Supplemental tags give software users and software management tools the ability to add helpful contextual information of local utility, such as license keys and contact information for relevant parties.

Organizations have some measure of flexibility when it comes to deciding which tags and specific data elements to include with their products. The SWID specification outlines a number of optional elements and attributes in addition to several required fields.

Ultimately, a minimal valid and conforming tag requires only a handful of elements that describe the software product (such as name and Tag ID) and the entity that created it. For the most comprehensive and up-to-date information on SWID Tag data elements, we recommend viewing the full ISO/IEC 19770-2:2015 Standard.

Cyclone DX

Per its website, Cyclone DX is “is a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis.” In other words, it aims to achieve a similar objective to SPDX, SWID, and really all SBOM delivery formats in providing key information about the software components that comprise an application.

Cyclone DX supports four categories of data:

  • Bill of Materials Metadata: Information on the application/product itself — the supplier, manufacturer, component the SBOM describes, and any tools used to compile an SBOM
  • Components: A complete inventory of proprietary and open source components, including licensing information
  • Services: External APIs that the software may call along with endpoint URI’s, authentication requirements, and trust boundary traversals
  • Dependencies: Both direct and transitive relationships

Other SBOM Formats

Although SPDX and SWID Tags and Cyclone DX are particularly common software bill of materials delivery formats, they aren’t the only ones. You can reference the NTIA’s Survey of Existing SBOM Formats and Standards report for a comprehensive list.

Benefits of Creating a Software Bill of Materials

The large number of different software components, dependencies, and licenses that are part of modern applications means managing them can be quite difficult. Without a software bill of materials, processes like conducting a risk assessment, doing due diligence around OSS license compliance (like identifying copyleft-licensed components), and remediating vulnerabilities can be incredibly time-consuming and painful.

The flip side of this, of course, is that a software bill of materials can go a long way toward managing risks in the software supply chain. Specifically, SBOMs help:

  • Achieve compliance with government regulations
  • Accelerate the process of identifying and remediating potential vulnerabilities
  • Enable manufacturers to meet attribution requirements that come with the use of many open source libraries
  • Reduce unnecessary work that could fall on development teams due to ambiguous supply chains
  • Provide transparency and build trust with consumers
  • Make it easier for manufacturers to identify and address a broken component post-release
  • Avoid significant business disruption in the event of an audit

Software Bill of Materials Use Cases

Clearly, there are many compelling reasons why organizations might look to create a software bill of materials. So, it’s recommended that organizations always create SBOMs for all products (and update them for any new release).

With that said, there are a few specific use cases where a software bill of materials may prove particularly valuable.

Fundraising, M&A, and IPO: A software bill of materials is an important part of the technical due diligence process that comes with a potential merger or acquisition, IPO, or fundraising round. Interested parties may request documentation to better understand the software components — and any license compliance, security, or code quality risks — within your products.  

Regulatory Compliance: As mentioned, the Biden Administration's new cybersecurity executive order on software supply chain security requires organizations that sell into the federal government to publish an SBOM with each product or as part of a public website.

Customer Requests: As preventing software supply chain attacks becomes an increasingly high priority for organizations across the globe, we expect more and more enterprises to require SBOMs as part of the purchasing and/or renewal processes.

Backward Compatibility: Companies that maintain a large volume of old software are often required to make OSS package updates and upgrades. Of course, it’s much easier to do this with a comprehensive inventory of the OSS in those legacy products.

Tools to Help Generate a Software Bill of Materials

It's safe to assume a software bill of materials will play an increasingly important role in the way business is conducted. But given the volume of data required to craft an SBOM, putting the pieces together via manual processes alone can be quite challenging.

Software composition analysis tools like FOSSA go a long way toward helping organizations build a software bill of materials. They:

  • Provide comprehensive and accurate data
  • Offer customizable reporting formats
  • Automate key steps in the SBOM creation process, saving teams significant time

For more information on how FOSSA can help your organization build or update a software bill of materials, feel free to get in touch with our team.