Standards and Formats

• 1: Minimum Elements of an SBOM
• 2: Identifiers and Licenses

1 - Minimum Elements of an SBOM

Once a format is chosen, the next question is what that format must contain. The documents that define this floor are the US Minimum Elements series. Though they are recommendations, they function as the de facto standard for federal procurement, and SBOM requirements in the EU and other jurisdictions largely reference this same framework.

Lineage: From NTIA 2021 to CISA 2025

The National Telecommunications and Information Administration (NTIA) published The Minimum Elements For a Software Bill of Materials (SBOM) in July 2021, under the delegation of Executive Order 14028. The document organized the minimum elements into three categories: the data fields to track per component, automation support requiring a machine-readable format, and practices and processes covering generation frequency, depth, and the like.

Stewardship of the community’s work then moved to the Cybersecurity and Infrastructure Security Agency (CISA), and two lines of revision followed. One was the third edition (September 2024) of Framing Software Component Transparency, a reference document that defines attributes, which added License and Copyright Notice to the baseline attributes. The other was a revision of the minimum elements document itself: CISA released 2025 Minimum Elements for a Software Bill of Materials as a public comment draft in August 2025, with the comment period closing on October 3, 2025. As of June 2026, this revision remains in draft status, and the date of a final version has not been confirmed.

The Data Fields and Three Categories of NTIA 2021

The NTIA 2021 minimum elements set seven per-component data fields.

The three categories are as follows.

• Data fields: The seven items above — the basic information for tracking and identifying components.
• Automation support: Specified SPDX, CycloneDX, and SWID as standard formats for automated generation and machine readability.
• Practices and processes: Covers generation frequency, depth, handling of known unknowns, distribution and delivery, access control, and how errors are accommodated.

What the CISA 2025 Draft Adds

The CISA 2025 minimum elements draft expanded the data fields to reflect the maturing state of tooling. Four core elements were newly added.

Existing items were also revised. The roles of SBOM Author and Software Producer were distinguished, “Other Unique Identifiers” was updated to “Software Identifiers,” and the access control element, previously separate, was folded into the distribution and delivery item. The trajectory of License — entering as a baseline attribute in Framing 3rd edition and hardening into a data field in the 2025 draft — shows that the SBOM is establishing itself as primary data for open source license compliance, beyond a security inventory. Behind adding Tool Name, Generation Context, and Hash together lies the concern that an SBOM produced by an untrustworthy tool cannot itself be trusted. Tool integrity is covered in 5. Tools and Automation.

Practical Recommendations

The minimum elements are, as the name says, a floor. Organizations can, and should, add fields suited to their own purposes. Carrying CVE references and patch status for vulnerability identification, SPDX license identifiers and copyright notices for license management, and release and End-of-Life dates for lifecycle management, together in one SBOM, lets a single SBOM answer multiple operational questions. If you are introducing an SBOM for the first time, starting with the NTIA seven fields as a base but including the four new fields from the CISA 2025 draft — especially hash and license — from the outset saves the effort of rebuilding it later.

Sources

NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf. CISA (2024). Framing Software Component Transparency, Third Edition. https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024. CISA (2025). 2025 Minimum Elements for a Software Bill of Materials (SBOM) (public comment draft). https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom. (All retrieved: 2026-06-14)

2 - Identifiers and Licenses

If the same component is named differently across SBOMs, automated matching breaks down, because there is no way for a machine to know that “Apache Tomcat,” “tomcat,” and “Apache Software Foundation Tomcat” are the same thing. This is why an identifier system that consistently points to components, and a convention for notating licenses with standard codes, are both necessary.

Three Identifiers: PURL, CPE, SWID

The three identifiers used together in practice serve different roles. They are not mutually exclusive, so recording them together where possible is recommended.

Table 1. Identifiers used together in an SBOM (source: purl-spec, NIST NVD, ISO/IEC 19770-2. Retrieved 2026-06-14)

A Package URL points to a component within a package manager ecosystem in the following format.

pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1
pkg:npm/lodash@4.17.21
pkg:pypi/requests@2.31.0

After pkg: come the ecosystem type (maven, npm, pypi, etc.), namespace, name, and version. Because the same component can be pointed to with the same string everywhere, it links automatically to vulnerability databases and license databases.

CPE was developed by MITRE in the mid-2000s and is now maintained by NIST. It notates products under a fixed naming rule and is used to look up the vulnerabilities (CVEs) corresponding to a product. SWID is a tag format standardized as ISO/IEC 19770-2 that structurally describes a product’s version and producing/distributing entity, and it is mainly used in asset management. The CISA 2025 minimum elements draft updating “Other Unique Identifiers” to “Software Identifiers” also reflects the maturing of this identifier ecosystem.

License Notation: SPDX License Identifiers

License management is one of the earliest use cases for an SBOM. Recording exactly which license each component is distributed under is what prevents obligation violations and conflicts in advance. Free-text descriptions cannot be matched automatically, so standard codes are used.

SPDX license identifiers assign each license a unique code such as Apache-2.0, MIT, or GPL-3.0-only. When multiple licenses apply together, they are combined with a license expression.

Apache-2.0 OR MIT
GPL-2.0-only WITH Classpath-exception-2.0
(MIT AND BSD-3-Clause)

OR indicates a choice among multiple licenses, AND indicates multiple licenses applying simultaneously, and WITH indicates combination with an exception clause.

The principles to follow in practice are as follows.

• The license of every individual component, not just the license of the product as a whole, must be visible.
• When encountering a license not on the standard list, assign it an identifier with a prefix indicating its source (for example, a LicenseRef- prefix) to track it.
• If the license text has been trivially modified but its meaning has not changed materially, use the same identifier as the original.
• Analyze license compatibility to identify in advance the conflicts that can arise when combining components under different licenses.

Even when a license field is auto-extracted by a tool, its accuracy is a separate matter. Precisely identifying non-standard licenses, handling dual licensing, and confirming compliance with licenses that carry field-of-use restrictions remain the responsibility of people and policy. The boundary of automation is covered in 5. Tools and Automation.

Sources

Package URL specification https://github.com/package-url/purl-spec. NIST. Common Platform Enumeration (CPE) https://nvd.nist.gov/products/cpe. ISO/IEC 19770-2:2015. SPDX License List https://spdx.org/licenses/. SPDX License Expressions https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/. (All retrieved: 2026-06-14)