Say it plainly and early: what the SBOM covers, what it does not, why, and when you expect to improve it. The NTIA report requires authors to identify known unknowns explicitly and asks consumers to tolerate good faith gaps, though not intentional obfuscation or willful ignorance.
What NTIA says about gaps
The report says that when the full dependency graph is not enumerated, the author must explicitly identify known unknowns, distinguishing between a component with no further dependencies and a component whose dependencies are unknown or incomplete. It says the default reading should be that the data is incomplete, and that the author should affirmatively state when a component's direct dependencies are fully enumerated. Its section on accommodating mistakes says consumers should welcome supplements and corrections without penalty when offered in good faith.
A cover note that works
Use a short note with four parts.
| Part | Example |
|---|---|
| Coverage | Includes all direct and transitive dependencies resolved at build time for the web application |
| Gaps | Does not include operating system packages in the customer's chosen base image; includes two vendored libraries without version data |
| Reason | Tooling cannot resolve versions for vendored code |
| Plan | Version data to be added in the next release, with a revised SBOM sent to you |
Steps
- Produce the SBOM and list every component with missing supplier, version or identifier.
- Use the format's explicit unknown or no assertion values rather than empty fields. Empty looks like an oversight, an explicit value looks like a decision.
- Mark dependency completeness where your format supports it.
- Write the cover note.
- Offer a call only if the customer needs one. Many do not.
- Diarise the promised update and keep it.
Words to avoid
Avoid saying the SBOM is complete or comprehensive. Avoid calling gaps minor without evidence. Avoid blaming your tool. Customers care less about why and more about whether you know the limits and are working on them.
What this signals to buyers
An SBOM with honest unknowns often earns more trust than one that looks perfect. Experienced reviewers know that dependency data is hard to resolve for vendored code, binaries and containers. Stating the limits shows you understand yours.
Related: SBOM known unknowns explained.
Try it yourself
Open the demo and look for components whose details are limited. Practise writing the one line you would put in a cover note for each.
Click through it at your own pace, or open it full screen.
Quick check
Is an incomplete SBOM worse than none?
No. The NTIA report says starting is better than waiting for perfection, as long as gaps are stated and corrected.
What if the gap is something we would rather not disclose?
The tolerance in the guidance does not extend to intentional obfuscation, so do not hide it. Discuss restricted sharing terms instead.
Safeguard's SBOM and dependency scanning can help close gaps in dependency data, and the free scan will show what is currently resolvable.
Sources
Last reviewed: 19 October 2026.
