An SBOM you link from a trust page should state who authored it, which tool and version made it, the data format and version, when it was generated and at what stage, and its own version number. The 2026 CISA minimum elements list these as SBOM metadata. Add a signature where you can.
The metadata a reader should find
The 2026 CISA guidance, co-authored with partner agencies, splits fields into metadata about the SBOM document and data about each component. For the document, it names the following.
| Field | What it tells a reader |
|---|---|
| SBOM Author | The entity that created the SBOM, not the tool |
| SBOM Author Signature | A digital signature attributable to the author |
| SBOM Data Format Name and Version | The format, such as SPDX or CycloneDX, and its version |
| SBOM Generation Context | Lifecycle stage, such as before build, build, or after build |
| SBOM Timestamp | Date and time of the latest update |
| SBOM Tool Name and Version | Which tool produced it |
| SBOM Version | Which revision of the SBOM this is |
Those are mostly new in the 2026 version, replacing the narrower 2021 NTIA list. If you published SBOMs under the old list, check them against this table.
Why generation context matters
The guidance gives an example: an SBOM made from source code could be labeled "before build," while a binary analysis tool can generate one "after build." The component data can differ between stages, so a customer comparing two files needs to know which is which.
Component data to spot check
For each component, the guidance lists producer, name, version, identifiers such as CPE or Package-URL, a hash value and algorithm, license, and dependency relationships. Spot check a few components. If a field is not known, the guidance says to state explicitly whether it is unknown to the author or being withheld, not to leave it blank.
Make the link itself useful
- Use a stable, version-specific URL. The guidance lists a version-specific URL as one way to deliver SBOMs.
- Name the file with product, version, and format.
- Say which formats you offer. The guidance names SPDX and CycloneDX as the two widely used formats.
- Show the timestamp next to the link.
- Say how to ask for corrections. The guidance says authors should correct errors promptly.
A short pre-publish check
- Does each release have its own SBOM, as the guidance's Frequency element expects?
- Does the file declare a current, non-deprecated format version?
- Is the author name a full entity name, not an acronym or a person's initials?
- Can a customer find the SBOM from the release notes and from the page?
- Have you signed it, or noted why not?
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the fields recorded for each component and compare them with the list above.
Where Safeguard fits
Safeguard's SBOM and dependency scanning generates the inventory behind a shared file, and the free scan at gold.safeguard.sh/scan shows what a scan finds in a project.
Quick check
Do I have to sign the SBOM?
The 2026 guidance lists an author signature among the elements. Where you cannot sign yet, say so and plan for it.
Which format should I publish?
The guidance names SPDX and CycloneDX as the two widely used formats. Offer the one your customers' tools read, and consider both.
Sources
Last reviewed: 19 October 2026.
