What are the seven data fields the NTIA minimum elements require in an SBOM?
answer
- seven, and two are about the document
- who supplied it, what, which version
- one field is the graph edge
- author is not always the supplier
- no component hash in the minimum
basics
~20 sSupplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. Four identify the component, one records structure, two describe the document itself. A component hash is not among them.
solid answer
~50 sThe NTIA minimum elements name seven data fields to be recorded for each component: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of SBOM data, and timestamp. Four of them identify the thing (`supplier`, `name`, `version`, plus a machine-usable key such as a purl or a CPE in the identifier field). One is structural: the dependency relationship, recording that an upstream component is included in something else. Two describe the document rather than the software: who authored these SBOM entries, and when this record was assembled. Notably absent are a cryptographic hash of the component, licence, lifecycle phase and anything about vulnerabilities — those sit outside the minimum. The point of the list is that it is a floor for a consumer to do anything useful, not a description of a good SBOM.
go deeper
Be ready to name all seven fields without hesitating and to say plainly that an SBOM is an inventory of components, not a list of vulnerabilities.
Explain why identifiers are a separate field from name and version, and which useful things — hash, licence, vulnerability data — are deliberately outside the minimum.
Show that field conformance says nothing about depth or generation vantage point, and describe what you would demand from a supplier on top of the seven fields.
Own the position that 'NTIA-conformant' in a contract is a floor, and decide what additional evidence your organisation requires before accepting a supplier's inventory as usable.
## What the minimum elements are In 2021 the US National Telecommunications and Information Administration (NTIA) published *The Minimum Elements For a Software Bill of Materials* — a baseline saying what any SBOM has to carry before a consumer can do anything with it. It is explicitly a **floor**, expected to grow, and it is not a description of a good SBOM. (The procurement mandate that caused it to be written is a separate subject; this is about the fields themselves.) The publication has three parts. **Data fields** are the seven below. **Automation support** requires a machine-readable format that a machine can also generate — SPDX, CycloneDX and SWID tags are the named ones. **Practices and processes** cover how often you issue an SBOM, how deep it goes, and how you deliver it. Candidates who can only recite the seven fields have read a third of it. ## The seven data fields Recorded for each component in the software: 1. **Supplier Name** — the entity that creates, defines and identifies the component. For a third-party library this is the upstream project or vendor, not you. 2. **Component Name** — the name the supplier gives it. 3. **Version of the Component** — the identifier the supplier uses to distinguish this release from earlier ones. 4. **Other Unique Identifiers** — additional keys that let a machine find the component in other databases: a package URL (`pkg:nuget/[email protected]`) or a CPE string. 5. **Dependency Relationship** — that an upstream component X is included in software Y. This is the only field that carries structure. 6. **Author of SBOM Data** — who produced *these entries*. Often not the supplier: a downstream integrator that regenerates or merges documents is the author of what it emits. 7. **Timestamp** — the date and time this SBOM record was assembled. A useful grouping: fields 1–4 identify the component, field 5 is the graph edge, fields 6–7 are metadata about the document. ## Why identifiers are separate from name and version Names are ambiguous. Two ecosystems can ship unrelated code under one name; the same code is repackaged under different names in different distributions. Matching a component against advisory data automatically needs a key that carries the ecosystem, which is what a purl does, or a CPE-style key for products that predate purl. Where that field is left blank, the component drops out of every automated match: on a card-authorisation service whose identifier field was populated for some money-moving components and blank for others, the one component that signed settlement batches could not be keyed at all — it was only ever going to be checked by hand, if anyone remembered. ## What the seven fields deliberately do not include - **No cryptographic hash of the component.** Hashes are discussed as a beyond-the-minimum addition, not a required field. Many producers include one anyway, and should — but conformance does not turn on it. - **No licence, no lifecycle phase, no component role.** - **No vulnerability data, severity or exploitability claim.** An SBOM is an inventory; whether a listed component is a problem in this build is a separate statement. - **No account of how the artifact was built, and no assertion of who vouches for it.** Those are different documents with different owners. Getting the direction right is the thing interviewers actually listen for: an SBOM says *what is inside*. It does not say how it came to be, and it does not say the contents are safe. ## Why the floor matters in practice Two SBOMs can both satisfy all seven fields and be worth wildly different amounts, because the fields say nothing about **where the list came from** or **how deep it goes**. A document listing only direct dependencies satisfies the field list for every entry it contains and still hides most of the tree. That is why the minimum elements pair the fields with depth and known-unknowns requirements, and why 'it is NTIA-conformant' is a starting condition in a contract negotiation rather than the end of one.
- Why is there an 'other unique identifiers' field when name and version are already required?Because a name plus a version is not a key. The same name means different code in different ecosystems, and repackaging renames things. A purl or CPE carries the ecosystem and namespace, so a machine can match the component against advisory data. A blank identifier field quietly removes that component from every automated check.
- Is a cryptographic hash of each component one of the required fields?No. Hashes are treated as a valuable addition beyond the minimum, not part of the seven. That is a real gap: without one, an entry asserts a name and version but gives no way to confirm the bits in the artifact are the bits the entry describes. Most mature producers emit hashes regardless.
- Does an SBOM that meets all seven fields tell you the software is free of known vulnerabilities?No. There is no vulnerability, severity or exploitability field in the minimum elements at all. The SBOM is the inventory you feed into that analysis; the analysis and its result are separate artifacts produced later and refreshed as advisories appear.
It is a shipping manifest: sender, item, model number, a barcode, what is packed inside what, who typed the manifest, and when. It never claims the contents are safe to open.
saying these in an interview costs you the question
- Says an SBOM lists vulnerabilities rather than components
- Claims a component hash is one of the required fields
- Treats supplier and author of SBOM data as one party
- Assumes name plus version uniquely keys a component
- Calls the minimum elements a quality bar rather than a floor
- Thinks conformance implies the full dependency tree is listed