Handle a customer SBOM request as a small repeatable process: confirm what they need and why, generate the right SBOM for the exact release, check it before it leaves, deliver it with stated terms, and log what you sent. A fixed intake turns a scramble into a same-week answer.
Why a workflow beats ad hoc replies
SBOM requests arrive through sales, support, procurement portals and security questionnaires. If each one is answered by whoever sees it first, customers get different formats, different depth and different promises. The NTIA minimum elements report treats the arrangement around an SBOM as part of the deliverable. It says frequency, depth, known unknowns, distribution, access control and tolerance for mistakes should be addressed in any policy, contract or arrangement. An intake process is how you make those choices once instead of per customer.
The five steps
| Step | What you do | Output |
|---|---|---|
| 1. Confirm | Ask which product and version, which format, and what the customer will do with it | A written request |
| 2. Scope | Pick the SBOM type that matches the question (source, build, or deployed) | A named scope |
| 3. Check | Validate the file and read it for fields you do not want to leak | A reviewed file |
| 4. Deliver | Send through a controlled channel with usage terms | A delivery record |
| 5. Log | Record version, date, recipient and any promises about updates | A request log entry |
Step 1: confirm the ask
Many requests are vague. "Send us your SBOM" can mean a file for one release, a feed for every release, or a regulator driven attachment. Ask for the product name, version, preferred format (SPDX or CycloneDX are the common ones) and the tool or team that will read it. Two questions save most rework: is a machine-readable file required, and do they also expect vulnerability status?
Step 2: scope the SBOM
Decide whether the customer wants what you built from, what you shipped, or what runs in their environment. Describe the scope in the cover note so nobody assumes more than the file contains. The NTIA report asks authors to mark known unknowns explicitly, so say where your dependency data stops.
Step 3: check before sending
Open the file and confirm that the document identifies the right version, carries the author and a timestamp, and lists components with supplier, name, version and unique identifiers. The NTIA report lists those baseline fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp. Also look for internal registry URLs or private package names you would rather not publish.
Step 4: deliver with terms
The NTIA report notes that if access control is desired, the terms must be specified, including allowances for loading the data into the customer's security tools. Use a channel you can audit, such as an authenticated portal or an expiring link, and say in plain words what the customer may do with the file.
Step 5: log it
Keep a short record: who asked, which release, which file hash, when, and whether you promised updates. When you later correct the SBOM, you will know who to tell.
Try it yourself
Open the demo and look at how an inventory lists direct and transitive components with versions. That is the content you are reviewing in step 3.
Click through it at your own pace, or open it full screen.
Quick check
Do we need a different SBOM for every customer?
No. Generate one per release and share the same file under different terms where needed. Customers differ in format preference and access rules, not in the facts about the build.
How fast should we answer?
Set an internal target and publish it to your sales and support teams. The sources do not set a response time, so choose one you can meet every time.
If you want to see what your own dependency inventory looks like before a customer asks, the free scan shows it, and Safeguard's SBOM and dependency scanning can keep it current.
Sources
Last reviewed: 19 October 2026.
