The hidden work in tracking SBOMs by hand is the recurring, unglamorous tasks around the file: collecting it, reshaping it, reconciling versions, answering one off questions, and rebuilding evidence for audits. None is large alone. Together they decide whether the process survives staff changes.
Why it stays hidden
A spreadsheet looks free. Nobody logs the hour spent copying output into rows, or the afternoon spent answering a customer's "do you use this library?" The cost is spread across people and weeks, so it never appears as a line item. This post lists the tasks so you can measure them yourself. It deliberately gives no numbers, because your volumes and tools are your own.
The seven recurring tasks
| Task | What it involves | Where it goes wrong |
|---|---|---|
| Collect | Ask teams and suppliers for the current file | Late, missing or the wrong version |
| Reshape | Convert formats, flatten into rows | Fields dropped, relationships lost |
| Reconcile | Match names across tools and suppliers | Duplicates, near misses |
| Update | Refresh after each release | Skipped under deadline pressure |
| Answer | Respond to "which products use X?" | Slow, and depends on who is available |
| Prove | Assemble evidence for customers and auditors | Reconstructed from memory and email |
| Hand over | Train a new owner | Knowledge sits in one head |
How to measure it
Pick one month and keep a simple tally.
- Count the requests you answered about components, SBOMs or advisories.
- For each, write how long it took and how many people were involved.
- Count the releases where the sheet was updated late or not at all.
- Note every correction you had to make after a customer or auditor spotted an error.
- List the tasks that only one person can do.
You now have your own evidence. If the tally is short and calm, a sheet is serving you. If it is long, that is the case for change, in your own numbers.
Risks that are not about time
Staleness. A sheet updated by hand is wrong sooner or later, and the person reading it does not know when. The NTIA guidance includes frequency as a practice to define for exactly this reason.
Single owner dependence. If one person holds the process, leave and illness are risks to your software transparency.
Error accumulation. Each manual step adds a small chance of error. Across hundreds of components the chance that a row is wrong approaches certainty, though it may never be noticed.
Slow response. When a major advisory lands, the time to find affected products matters most. A manual process is slowest exactly when you need speed. Reading about rescanning stored SBOMs when a new advisory lands shows what automation can do here.
What to automate first
Start with the tasks that are repetitive and rule based: generation in the build, ingest, matching against advisories and the diff between releases. Leave the human judgement, such as deciding whether a vulnerability is not affected, to people, with notes recorded. See from inventory to insight for turning data into priorities.
Where Safeguard fits
Safeguard automates SBOM and dependency scanning and uses reachability analysis to cut noise, so people spend time on findings that can matter. The free scan at gold.safeguard.sh/scan shows the output for one of your repositories.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how many findings drop out of the work list once reachability is considered.
Quick check
How do I make the case for a platform without invented numbers?
Run the one month tally above and present your own counts, delays and corrections.
Which task should I automate first?
Generation and ingest, because every later step depends on them being current.
Sources
Last reviewed: 19 October 2026.
