To get a usable SBOM, name the exact product and version, the formats you accept, the depth you expect, how often it should be refreshed and how it will be delivered. Then validate what arrives. A request that says only "send your SBOM" invites a file you cannot use.
What to put in the request
- Scope. Product name, version or release line, and which deployment: hosted, self managed, mobile or firmware.
- Format. Name the formats you can read, such as CycloneDX or SPDX, and the file type.
- Content. Ask for the fields in the current minimum elements guidance, including supplier, component names, versions and dependency relationships. Check which edition you are relying on; see which SBOM minimum elements to follow.
- Depth. Include transitive dependencies, not only direct ones.
- Type. Say which SBOM type you want: source, build or deployed. See which SBOM type to ask a supplier for.
- Refresh. On every release, or on request when a new vulnerability appears.
- Delivery and handling. Secure channel, who can see it, and any confidentiality terms.
Sample wording
You can adapt this text.
We are reviewing Product X version 4.2 as deployed in your hosted service. Please send an SBOM in CycloneDX or SPDX JSON that includes direct and transitive components with supplier, name, version and dependency relationships. Please tell us how often it is regenerated and whether you can provide an updated copy when a new vulnerability in a component is announced. We will keep it confidential and share it only with our security team.
Check what you receive
| Check | Why |
|---|---|
| Does the file parse? | Broken files are common |
| Are versions present? | Without versions you cannot match advisories |
| Are there transitive components? | A direct list hides most of the tree |
| Does it match the product and version you named? | Wrong scope is a frequent error |
| Is the timestamp recent? | Old SBOMs describe old builds |
See validate an SBOM before you accept it for tools and steps.
If the supplier hesitates
Some suppliers worry about exposing their components. Offer a nondisclosure agreement, accept a redacted file where the redaction is documented, or ask for the same facts through a vulnerability statement. If they refuse outright, see what to do when a supplier will not provide an SBOM.
Try it yourself
Open the dependency inventory demo to see what a component list with versions looks like, then use it as a mental checklist when an SBOM arrives.
Click through it at your own pace, or open it full screen.
Quick check
Should I ask for both CycloneDX and SPDX?
Usually one is enough. Ask for the one your tools read best, and say so in the request.
How often should I ask for a new SBOM?
Ask for one with each release you deploy, and again when a major vulnerability in a likely component is announced.
Safeguard can ingest and scan supplier SBOMs and match components to known vulnerabilities, and a free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
