Promise only what you can deliver every time. The NTIA minimum elements report lists six practices to address in any SBOM arrangement: frequency, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes. Settle each in writing before you agree to supply SBOMs.
The six practice areas
The NTIA report says a number of elements should be explicitly addressed in any policy, contract or arrangement to ask for or provide SBOMs. Here they are, with what each means for a vendor.
| Practice | What NTIA says | What to commit to |
|---|---|---|
| Frequency | New build or release needs a new SBOM; corrections warrant a revised one | A new SBOM with each release, plus corrections |
| Depth | All top level components, with transitive dependencies listed; at a minimum, top level with enough detail to find the rest | A stated depth, such as all transitive dependencies in the build |
| Known unknowns | Say explicitly where the dependency graph is not fully enumerated | A statement of what is not covered |
| Distribution and delivery | Available in a timely way, with proper access roles | A channel and a timeframe |
| Access control | Public or restricted; if restricted, terms must be specified | Who may receive and use it |
| Accommodation of mistakes | Consumers tolerate good faith errors; suppliers offer updates | A correction process |
Drafting tips
- Frequency: tie it to releases, not to calendar dates, unless you can automate calendar delivery. A promise to send monthly files for software that changes weekly invites gaps.
- Depth: do not promise complete graphs you cannot produce. The report notes depth beyond top level components may not be easily available, and that some use cases need complete graphs. Describe your actual depth.
- Known unknowns: add a standing sentence that components your tooling cannot resolve are marked as such.
- Delivery: name the channel, the response time and the format. Avoid promising every format under the sun.
- Access: allow ingestion into the customer's security tools, which the report specifically calls out.
- Mistakes: say that you will issue corrections and that the customer will treat good faith errors as corrections, not breaches. The report says this tolerance does not cover intentional obfuscation.
What not to put in
Avoid warranties that the SBOM is complete or free of errors. Avoid promising vulnerability status unless you also commit to VEX or advisories. Avoid tying SBOM delivery to payment milestones.
Coordinate with legal and engineering
Legal drafts the clause, engineering confirms what is possible, and security reviews the sharing terms. A one page internal standard that all three agreed on shortens every negotiation.
Related: the SBOM on request contract clause.
Try it yourself
Open the demo and look at the depth of its dependency view. Ask whether you could honestly promise that level for your own product.
Click through it at your own pace, or open it full screen.
Quick check
Do we have to commit to full transitive depth?
The NTIA report says, at a minimum, top level dependencies must be listed with enough detail to find the transitive ones. Commit to what you can do.
Should the contract name an SBOM format?
You can, but prefer allowing a short list. NTIA names SPDX, CycloneDX and SWID tags as the formats of its time.
Safeguard's SBOM and dependency scanning can help you meet a depth and frequency you have promised, and the free scan shows your current depth.
Sources
Last reviewed: 19 October 2026.
