NTIA Publishes SBOM Minimum Elements: The Seven Fields That Define a Valid SBOM

Why Minimum Elements Matter

Before the NTIA guidance, different organizations generated SBOMs with wildly different structures. Some included vulnerability data. Others included only package names. Many were human-readable PDFs rather than machine-readable files. The result was an ecosystem where SBOMs existed but could not be meaningfully consumed or compared across organizations.

The minimum elements framework solves this by establishing a common baseline. Any SBOM that includes these seven fields can be ingested by automated tools, cross-referenced against vulnerability databases, and audited by regulators — regardless of which tool generated it or which format it uses.

The Seven Fields Explained

1. Supplier Name — The entity that creates, maintains, or distributes the component. For open source packages, this is typically the project's maintaining organization. For commercial components, it is the vendor.

2. Component Name — The canonical name of the library, module, or package — matching the name used in the relevant package registry for reliable identification.

3. Version of the Component — An exact, resolved version number. Version ranges are not acceptable. This field is what enables precise CVE matching against vulnerability databases.

4. Other Unique Identifiers — A Package URL (PURL) or Common Platform Enumeration (CPE) string that uniquely identifies the component across systems and enables cross-referencing with NVD and other databases.

5. Dependency Relationship — The graph structure showing which component depends on which others. This enables downstream impact analysis — if Component A is vulnerable, which other components and applications are affected?

6. Author of SBOM Data — Who generated the SBOM. In automated pipelines, this is typically a tool name and version. This field enables trust evaluation of the SBOM's completeness and accuracy.

7. Timestamp — When the SBOM was created. This enables time-based analysis and helps auditors understand how current the SBOM is relative to the software it describes.

What the Minimum Elements Do Not Cover

The NTIA was deliberate about calling these "minimum" elements. They deliberately excluded license data, vulnerability information, and file-level hashes from the mandatory set — not because these are unimportant, but because requiring them immediately would have made compliance unachievable for most organizations. The expectation is that the ecosystem matures toward more comprehensive SBOMs over time.

Implications for Tooling

The publication of minimum elements immediately created a clear benchmark for SBOM generation tools. Any tool claiming NTIA compliance must produce all seven fields for every component it identifies. Organizations evaluating SCA platforms should verify that their tool's SBOM output is complete against this checklist — especially the dependency relationship graph, which many simpler tools omit.