Yes, a spreadsheet can be enough for a small company with a few products, infrequent releases, no supplier SBOMs to ingest and no customer or regulator asking for SBOMs often. Once two or more of those conditions change, plan a move. Even then, the sheet can stay as a reporting view.
The decision guide
Answer each question with yes or no.
- Do you have more than three products or services with their own releases?
- Do you release more than once a month?
- Do customers or partners ask you for SBOMs?
- Do you receive SBOMs from suppliers that you need to track?
- Does an auditor, regulator or contract require dated records or proof of access control?
- Do more than two people update the data?
- Have you had a late or wrong answer about a component in the last year?
| Yes answers | Suggested path |
|---|---|
| 0 or 1 | Sheet plus generated files in version control |
| 2 or 3 | Sheet for now, pilot a platform on two products |
| 4 or more | Move to a platform, keep the sheet as a view |
This is a rule of thumb, not a standard. Adjust it for your risk. A company that sells into a regulated sector may need the platform at one yes, because the regulator's question sets the pace.
What a good small company setup looks like
If you stay on a sheet, do it properly.
- Generate SBOMs in the build and keep the files in the repository or with release artifacts.
- Use the columns recommended here, including product, release and a stable identifier.
- One sheet per release. Never overwrite.
- Name an owner and a backup.
- Add a calendar reminder to regenerate for each release.
- Test a retrieval from last year once a quarter.
For storage conventions see commit an SBOM to git or generate it in CI.
Triggers to watch
Write down the events that will make you reconsider. Examples: a first customer who asks for SBOMs on a regular basis, a first supplier file to ingest, an audit that asks for point in time proof, or your second product line. Setting the triggers now avoids a rushed choice later. The ten warning signs give more.
Do not skip the basics
Whatever tool you use, the SBOM itself must be good. A sheet of incomplete data is worse than none, because it looks authoritative. Check depth and unknowns, and say so when the SBOM is partial, as in how to tell a customer your SBOM is incomplete.
Free options exist
Small teams often start with free generators and scanners, and that is a sound start. The guide on free SBOM tools versus paid platforms explains where free stops being enough.
Where Safeguard fits
Safeguard offers a free scan at gold.safeguard.sh/scan that produces an SBOM and dependency inventory for a repository, which is a practical way to fill your first sheet or to see what a platform would show. Its SBOM and dependency scanning and compliance evidence automation are there for when the work outgrows the sheet.
Try it yourself
Click through it at your own pace, or open it full screen.
See how big a real dependency inventory gets, then judge whether a sheet would stay manageable.
Quick check
Is it acceptable to start with a spreadsheet?
Yes, as long as the SBOMs are generated, dated and kept per release. The sheet is a view, not the source.
What is the single best trigger to move?
The first time you cannot answer a component or audit question quickly. That is the event the platform exists to prevent.
Last reviewed: 19 October 2026.
