In the NTIA minimum elements, "Author of SBOM Data" is the entity that created the SBOM data for a component. It is not the author of the software itself. It can be the software's creator, an upstream supplier, or a third party analysis tool. Read it as a clue about how much to trust the record.
Definition
The NTIA report lists seven baseline data fields: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp. It defines the author field as the name of the entity that creates the SBOM data for a component.
The report adds a clarification worth underlining: this is not the author of the software, just the source of the descriptive data. It says the source could be the creator of the software being described, the upstream component supplier, or a third party analysis tool.
Three field pairs that get confused
| Field | Answers | Example reading |
|---|---|---|
| Supplier Name | Who originated or manufactures the component? | The project or company behind a library |
| Author of SBOM Data | Who wrote this SBOM record? | Your build team, or a scanning tool |
| Timestamp | When was the SBOM data assembled? | The moment the record was created |
The supplier is about the component. The author and timestamp are about the document. NTIA calls these SBOM specific metadata, and says they help track the SBOM itself and give context to the data source, which can be used in trust decisions.
Why the author matters when you read an SBOM
Consider three SBOMs for the same product:
- Author is the product team. They know their build. The data may be complete, but you are trusting their process.
- Author is an upstream supplier. Component level facts may be accurate for that supplier's own parts, but the product team may have added others.
- Author is a third party tool. The data came from inspecting an artifact, and heuristics may have left gaps.
None of these is wrong. They answer a different question about confidence. If you receive a file whose author field says only the name of a tool, ask who ran it and on what.
How to fill it in on your own SBOMs
- Name the real entity or tool that generated the file, including a version if the format allows.
- If your pipeline combines several sources, say so in a note and keep the main producer in the field.
- Do not put the lead developer's name in the field because they wrote the code. That answers a different question.
- Keep the timestamp in the same record, and regenerate both together when the SBOM is rebuilt.
A worked example
A team builds a service in CI. Their SBOM tool runs in the pipeline on 19 October 2026. The metadata should say the tool, with its version, and the organization that operates the pipeline, plus the date and time. A reader can then tell that this is machine generated during the build, not a hand written list or a vendor's marketing sheet.
Now imagine the team passes the file to a customer, who runs a second scanner and adds findings. The customer's tool becomes the author of its own record. Two documents, two authors, two timestamps. That is normal. Do not overwrite the original.
Checking a supplier's SBOM
Add these to your intake list: Is the author field present? Does it name an entity or only a tool? Is the timestamp recent compared with the release date? If the SBOM is much older than the release it describes, ask why.
For intake steps, see the first 30 minutes with a supplier SBOM. For versioning and dates, see how to version and timestamp an SBOM.
Safeguard generates SBOMs through its dependency scanning and records when they were built. The free scan is at gold.safeguard.sh/scan.
Quick check
Is the SBOM author the person who wrote the software?
Not necessarily. NTIA says the field is the source of the descriptive data, which may be the creator, an upstream supplier or a third party tool.
Which fields describe the SBOM document rather than a component?
Author of SBOM Data and Timestamp. NTIA calls them SBOM specific metadata.
Sources
Last reviewed: 19 October 2026.
