Before sending an SBOM, ask the customer why they want it, which format they can read, who will receive it, how long they will keep it and whether it will be shared onward. Five short questions let you send the right file to the right people, and they take a few minutes.
Why ask at all
Requests for an SBOM arrive in many forms: a line in a questionnaire, a procurement checkbox, a one line email, a regulatory duty on the customer's side. Sending the same file to all of them wastes effort and sometimes causes harm. A customer who cannot open your format will come back with questions. A customer who wanted a license list receives a full dependency tree.
A short intake saves a second round of emails.
The intake questions
- What is the purpose? Procurement review, vulnerability management, license check, regulatory requirement, or internal inventory. The purpose decides how much detail to send.
- Which format and version can you consume? CycloneDX and SPDX are the common choices. If they have a tool, ask which version of the format it expects.
- Who will receive and use it? Names or roles. This drives access settings and expiry.
- How long will you keep it, and where will it be stored? This tells you whether to attach handling terms.
- Will it be shared with anyone else, such as an auditor or parent company? If so, treat those as extra recipients. See sharing evidence with a customer's auditor.
Optional extras: which release they run, and whether they want exploitability information alongside.
Turn the answers into a send
| Answer | What you do |
|---|---|
| Purpose is license review | Send components and licenses, lower detail |
| Purpose is vulnerability management | Send full SBOM, offer exploitability data |
| Format unusual | Convert and check the output before sending |
| Many recipients | Use a link with named access and expiry |
| Onward sharing | Name the extra recipients and confirm terms |
For converting, check the output carefully against the source. See compare SBOM output before and after a scanner switch for the idea of validating a changed file.
Where the SBOM request comes from
Sometimes the request comes from a regulation the customer must meet. CISA published its 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, updating and replacing the 2021 NTIA minimum elements, and notes that some software types, such as AI and SaaS, may need additional elements. If a customer cites minimum elements, ask which version they are checking against and confirm your file fits.
Keep the exchange light
Do not turn intake into a form that delays the deal. A two line message works: "Happy to send our SBOM. To send the right one, which format do you prefer, and who should receive it?" Most customers answer in one reply.
Record the answers in your sharing register so the next request from the same customer is faster. See track what you have shared with each customer.
Try it yourself
This demo shows a dependency inventory and the detail an SBOM can contain. Look at what a customer would see at component level, and decide what detail you would hold back.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning supports producing the inventory you send, and a free scan shows a sample.
Quick check
What if the customer does not know which format they need?
Offer CycloneDX or SPDX and ask what tool will read it. If they have none, send the format you produce and a plain summary.
Is intake worth it for small requests?
For a one line request, two questions about format and recipients are enough. Keep it proportionate.
Sources
Last reviewed: 19 October 2026.
