In an SBOM, how does the NTIA 'supplier name' field differ from 'author of SBOM data'?

## Two parties, two kinds of claim The minimum elements separate a fact about the **software** from a fact about the **document**, and the separation exists because in a real delivery chain they are almost never the same organisation. **Supplier name** identifies the entity that creates, defines and identifies the component — the upstream project or vendor. It is a property of the component and it should stay stable no matter who is writing the SBOM. **Author of SBOM data** identifies whoever produced these entries. If a vendor generates an SBOM for its own build, supplier and author coincide for the top-level component and diverge for every third-party dependency. If someone downstream regenerates or merges documents, the author is that downstream party. ## Why the divergence matters Consider a rail-dispatch service assembled by three organisations: an equipment OEM writes a signalling library, a systems integrator assembles the application, and the transit operator runs it. When the integrator merges the OEM's document with its own scan and re-exports, the resulting SBOM says `supplier: Rail Equipment OEM` for the library and names the integrator as the author. Three consequences follow. **The claim's owner changed.** The integrator is now asserting facts about someone else's software, limited by what it could see. If the OEM shipped a component whose internals the integrator could not decompose, the integrator's entries describe the OEM's software less completely than the OEM's own document did — and nothing in the field structure warns you of that. The author field is your cue to ask which document you are actually holding. **The timestamp moved.** The timestamp records when the SBOM record was assembled, not when the software was built. A re-export in March carries a March timestamp over firmware compiled the previous year. Teams that treat the timestamp as a freshness signal for the *software* conclude they are looking at a recent build; they are looking at a recent document. **Whoever fills the fields decides what the record says.** This is the field pair's uncomfortable property. An insider at the integrator who can choose what the merged document contains can drop an entry, and the resulting SBOM is still structurally conformant — every remaining component has all seven fields. The minimum elements are a data-quality baseline; they contain no mechanism that makes the record binding on its author. Turning a document into evidence somebody can be held to is a separate control, handled elsewhere, and it is worth saying so explicitly in an interview rather than pretending the field list does that work. ## Reading a document you were handed When a customer or auditor hands you an SBOM, read the metadata first: - **Who authored it?** The producer of the artifact, or a downstream re-exporter? A re-export is second-hand evidence. - **What is the timestamp relative to the artifact?** A document dated long after the build has been regenerated, possibly from a vantage point that sees less than the original build did. - **Does the top-level component's supplier match the party you have a contract with?** If it does not, you are looking at an inventory of someone else's product embedded in yours. ## Common confusion to avoid People collapse the two fields because in the simplest case — a vendor documenting its own release — they nearly coincide. In every multi-party chain they do not, and the entire value of the author field is that it tells you whose visibility and whose word the document represents. Asking 'who wrote this and when' is the first question of any SBOM review, and the minimum elements make sure the document can answer it.