Assume an honest error first and report it with specifics. The NTIA minimum elements report asks consumers to tolerate occasional good-faith mistakes, but not intentional obfuscation or willful ignorance. How the supplier responds, more than the mistake itself, tells you which one you are dealing with.
What the standard says
The NTIA report includes a practice called accommodation of mistakes. It says SBOM practice is still evolving, that starting today beats waiting for perfection, and that consumers should be explicitly tolerant of the occasional incidental error. Suppliers should offer updated data when they find issues, and consumers should welcome corrections without penalty when offered in good faith. It then adds that the tolerance should not apply to intentional obfuscation or willful ignorance.
That gives you a two part test: was the error honest, and does the supplier fix it?
Common honest errors
- A version listed one release behind.
- A component present in the product but missing because the generator did not see it.
- A name or identifier that does not match the registry.
- A timestamp from a build earlier than the shipped one.
- A flat list where the supplier thought relationships were included.
These happen with every tool. None implies bad intent.
Step by step
- Verify before reporting. Confirm the discrepancy using the delivered software, not only another SBOM.
- Write a specific note. Component, version you see, where you saw it, the SBOM line it conflicts with.
- Ask for a corrected file and a short cause. "What caused this, and does it affect other components?"
- Set a reasonable date. A week or two for most cases.
- Log everything. Date sent, reply, new file received.
Reading the response
| Response | What it suggests |
|---|---|
| Quick acknowledgement, corrected file, short cause | Good faith, working process |
| Slow but a correct fix | Process needs time; keep following up |
| Fix with no explanation | Acceptable once, ask about the generator |
| Denial despite evidence | Concern; escalate and verify other claims |
| Repeated omissions of the same kind | Pattern; ask for method details or a different data source |
| Refusal to discuss scope | Treat the SBOM as unreliable for decisions |
One mistake is a mistake. A pattern is worth discussing with a senior contact.
What not to do
Do not post the error publicly or accuse the supplier of hiding things on the basis of one omission. Do not impose penalties for honest corrections, since that teaches suppliers to stop sending updates. Do not rely on a single document to prove intent either way.
What to record for your own risk decisions
If the supplier's SBOMs have needed several corrections, lower the weight you place on negative searches ("component not present") from their files, and rely more on your own scans of delivered software. That is a reasonable adjustment, not a punishment.
Safeguard's SBOM and dependency scanning can scan what you received so you can compare, and the free scan is at gold.safeguard.sh/scan.
Quick check
Should we penalize a supplier for an SBOM error?
Not for honest errors. The NTIA report says to welcome corrections made in good faith. Your concern should grow when errors are repeated or explanations are evasive.
How soon should a supplier send a corrected SBOM?
There is no standard deadline. A week or two is a reasonable ask for most cases, agreed in your own terms.
Sources
Last reviewed: 19 October 2026.
