If you must track SBOM data in a spreadsheet, include the seven NTIA baseline fields, then add four columns that make the sheet survivable: product and release, source file name, a stable identifier such as a package URL, and a status. These extra columns are what make a later import into any tool possible.
The seven baseline fields
The NTIA minimum elements document lists these data fields for each component:
| Column | Meaning in plain words |
|---|---|
| Supplier name | Who creates or defines the component |
| Component name | The name the supplier gave it |
| Version | The supplier's version identifier |
| Other unique identifiers | Lookup keys for databases, such as a package URL |
| Dependency relationship | Which component includes which |
| Author of SBOM data | Who produced this record |
| Timestamp | When the record was made |
Treat these as your floor. Dropping any of them means the sheet cannot be turned back into a standard SBOM later without guessing.
Four columns worth adding
Product and release. Without this, the sheet cannot answer "what shipped in version 4.2?" Record the product name and the build or release identifier on every row. One sheet per release is cleaner than one sheet with a date filter.
Source file. Note the file name of the generator output the row came from, and keep that file. If a row looks wrong, you can compare it with the original instead of arguing from memory.
Stable identifier. A package URL gives a name, an ecosystem and a version in one string. It is far easier to match against advisories than a free text name. The post on package URL or CPE compares the options.
Status. A short controlled vocabulary such as under investigation, affected, not affected and fixed. Free text turns into noise within a month.
Rules that save you later
- One row per component per release. Do not merge releases into one row with a list of versions.
- Relationships as parent and child columns. A parent identifier column keeps the dependency tree recoverable. Without it, you hold a flat list.
- Dropdowns for status and scope. Validation rules cost nothing and prevent spelling drift.
- Lock the header row and the identifier column. Accidental edits to identifiers break every later lookup.
- Never overwrite. Copy the sheet for a new release. Overwriting destroys the history that a customer or auditor may ask about.
- Add a change log tab. Date, person, what changed, why. It is a poor substitute for an audit log, but it is far better than nothing.
What a sheet still cannot do
Even a well built sheet will not validate a file against its format specification, refresh when a new advisory is published, or restrict access by product. If you notice you are building those features with macros, that is the signal to look at a platform. The ten warning signs in when does an SBOM spreadsheet stop working describe the point in more detail.
Keep an export path open
Keep the original generator output in a folder per release. If you can regenerate the SBOM, the sheet is a view, not the source of truth. That one habit lowers the cost of every future change.
Where Safeguard fits
If you want the same fields without the manual work, Safeguard generates an SBOM and dependency inventory from a scan, and the free scan at gold.safeguard.sh/scan shows what a complete component list looks like for your own code.
Quick check
Do I need every NTIA field for every row?
Aim for it. When a value is truly unknown, say so explicitly in the cell instead of leaving it blank, so a reader can tell unknown from forgotten.
Should I keep one sheet or many?
One sheet per product release is easiest to reason about and to archive. A single giant sheet invites overwrites and filters that hide data.
Sources
Last reviewed: 19 October 2026.
