An SBOM spreadsheet stops working when the work around it grows faster than the data in it: more products, more releases, more people who need access, and more questions that need an answer the same day. There is no fixed size. Watch for the ten signs below instead of counting rows.
What a spreadsheet does well
Be fair to the spreadsheet. For one product with one release a quarter, a sheet with a component name, version, supplier and license is cheap, readable and easy to hand to an auditor. The NTIA minimum elements document lists seven baseline data fields for each component: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. A sheet can hold all seven. The trouble starts when the sheet has to behave like a system.
Ten warning signs
- Nobody can say which tab is current. Copies named final, final2 and final_use_this are the clearest sign.
- Updates are pasted by hand. Each release means copying output from a generator into rows, and the copy step is where mistakes enter.
- You cannot answer "which products use this component?" in a minute. If the answer needs a person with filters and a free afternoon, a new advisory will find you slow.
- Dependency relationships are missing. A flat list loses the parent and child links, so you cannot tell a direct dependency from a transitive one.
- Two people edited the same cell. Version history in a sheet shows that a cell changed, not why.
- Access is all or nothing. A customer success manager needs to see one product. The sheet shares everything or nothing.
- Releases are not preserved. Last month's state is overwritten, so a customer asking about an older version gets a guess.
- Different formats arrive and nobody normalises them. Supplier files come in several formats and each one is reshaped by hand.
- Audit questions take days. An assessor asks for proof of what shipped on a given date and you rebuild it from memory and email.
- The owner is on leave and the process stops. A process that lives in one person's head is a risk of its own.
How to score yourself
Count the signs that apply today.
| Signs that apply | What it usually means |
|---|---|
| 0 to 2 | The sheet is fine. Add a version column and a change log. |
| 3 to 5 | Stay on the sheet, but write down the pain points and a trigger for moving. |
| 6 or more | Run a short pilot of a platform on two or three real products. |
The score is a conversation starter, not a rule. One sign, such as an audit that needs a point in time record, can justify a move on its own.
What to do before you move
Fixing the data pays off on any tool. Pick one canonical identifier per component, such as a package URL. Record the release or build the SBOM belongs to. Keep the raw generator output next to the sheet so nothing is lost in translation. These three habits make a later import far less painful. The article on what to index when you store supplier SBOMs goes deeper on fields.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning with a component inventory, plus compliance evidence automation, so the inventory and the proof of it stay in one place. You can test a real repository with the free scan at gold.safeguard.sh/scan before deciding anything.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components, versions and relationships sit together, then compare that with the flat list in your sheet.
Quick check
Is there a number of products after which a spreadsheet is too small?
No standard number exists. The better test is whether you can answer a component question, an audit question and a customer question quickly and with the same data each time.
Can a spreadsheet hold a full SBOM?
It can hold the baseline fields. It struggles with relationships, nested components and history, which are the parts that make an SBOM useful over time.
Sources
Last reviewed: 19 October 2026.
