Send follow-ups that match what you saw in the file: which product and version it covers, how deep the dependency list goes, what the supplier knows about flagged components, and when you will get the next version. Specific questions get answers. A generic questionnaire gets a form letter.
Why a second round of questions helps
Most guidance focuses on what to ask before the SBOM arrives. Once it lands, you hold real evidence, and your questions can point at it. That changes the tone from audit to conversation.
The NTIA minimum elements report treats an SBOM as data plus practices. The data fields describe components. The practices cover frequency, depth, known unknowns, distribution, access control and accommodation of mistakes. Your follow-up should touch both.
The five questions
- Scope. "Does this file describe version X as deployed, or the latest build?" Components change between releases, so the answer decides whether the file applies to you.
- Depth. "Are transitive dependencies listed, and where the graph is incomplete, is that marked?" The NTIA report says an author must identify known unknowns, so the default reading of an unmarked gap is that the data is incomplete.
- Flagged components. "Component Y shows a known vulnerability. Is it present in the shipped product, and is it reachable?" This is where a VEX statement helps.
- Fixes. "Is a fixed version planned, and when?" Ask for a date range, not a promise.
- Cadence. "Will you send a new SBOM with each release or when you learn of an error?" The NTIA report describes this as the frequency practice.
A short reply you can adapt
"Thank you for the SBOM for product X version Y. We reviewed it and have four questions. First, does it describe the version we run? Second, are transitive dependencies included, and are gaps marked? Third, component Z shows a known vulnerability in public data. Can you tell us whether it affects your product? Fourth, how will we receive updates? A CycloneDX or SPDX file, or a VEX statement where relevant, is fine."
Keep the number of questions small. Four or five is enough for a first pass.
What good answers look like
| Question | A useful answer | A weak answer |
|---|---|---|
| Scope | Names version and build date | "The latest" |
| Depth | States levels covered and known gaps | "All dependencies" with no detail |
| Flagged component | Status with a reason, ideally as VEX | "Not exploitable" with no explanation |
| Fix | Version and rough timing | "We are looking into it" |
| Cadence | Per release and on correction | "On request" with no timing |
A weak answer is not a failure. It tells you where the supplier is in their process, and you can set a follow-up date.
Record it
Store the question list and the reply with the SBOM. If the supplier sends a corrected file, link it to the original. The NTIA report asks consumers to welcome corrections made in good faith, but not to tolerate deliberate obfuscation, so keep a record that lets you tell the difference.
Safeguard's SBOM and dependency scanning can turn the flagged components into a list you attach to the reply, and the free scan at gold.safeguard.sh/scan gives a quick first look.
Quick check
How many questions should the follow-up contain?
Four or five, each tied to something in the file. Long questionnaires slow replies without improving them.
Do we need the supplier to send VEX?
Not always. CISA describes VEX as an attestation about whether a product is affected by a vulnerability, and says whether to issue one is a business decision for most suppliers. Ask, but accept a plain written answer if that is what exists.
Sources
- The Minimum Elements For a Software Bill of Materials (SBOM), NTIA
- When to Issue VEX Information, CISA
- Software Bill of Materials (SBOM), CISA
Last reviewed: 19 October 2026.
