The government defined what a software parts list must contain

What the document says

On 12 July 2021, the Department of Commerce's National Telecommunications and Information Administration published The Minimum Elements for a Software Bill of Materials, required within 60 days by Executive Order 14028. It defines an SBOM as a formal record of a piece of software's components and their supply-chain relationships, and sets three categories of minimum requirement: data fields, including supplier name, component name, version, other unique identifiers, dependency relationships, the author of the SBOM data, and a timestamp; automation support through interoperable, machine-readable formats such as SPDX, CycloneDX and SWID tags; and practices covering how often an SBOM is updated, how much depth it covers, how gaps are disclosed, and how it is distributed and access-controlled.

Confidence and limits

The report's own text, retrieved on 16 September 2026, is the primary basis for this description; as a foundational document it does not itself change, though the practice it describes continues to evolve, and CISA's current SBOM page shows the concept has since been extended with related ideas such as the Vulnerability Exploitability eXchange. The report is explicit about its own limits: it states plainly that SBOMs will not solve all software security problems, that the minimum elements create no new federal procurement or regulatory requirement, and that questions of hardware supply chains and centralised SBOM repositories are outside its scope.

Why it mattered

Before this document, the software industry had no government-endorsed, minimum common definition of what a software bill of materials should actually contain, which meant organisations asking suppliers for one had no shared baseline to request. By defining seven required data fields and naming acceptable machine-readable formats, the report gave both buyers and vendors a floor to negotiate from rather than a blank page. Five months later, when the Log4j vulnerability exposed how few organisations could quickly determine where a single embedded library lived across their own systems, the report's core promise, that an SBOM should make exactly that kind of question answerable, took on immediate practical weight even though its own text had already outlived the immediate mandate that produced it.

Defensive takeaway

Ask your software suppliers whether they can produce an SBOM containing at minimum the seven data fields this report defines, in a machine-readable format, and treat a supplier's inability to do so as useful information about their own supply-chain visibility.

• Could your organisation produce a compliant SBOM for the software you build or maintain today?
• Do your existing vendor contracts request an SBOM, and in a format your tools can actually consume?
• When a new vulnerability is disclosed in a common component, how would you find out where it lives in your environment?

The report was always meant as a floor rather than a finished standard, and its authors said as much, so its usefulness depends on whether organisations actually ask for what it defines rather than treating its existence as sufficient on its own.