Do not stall and do not improvise. Generate an SBOM from your build, review it for gaps, share a summary or the full file under NDA, and say plainly what it covers. A first SBOM that is honest about its limits is better than a perfect one delivered after the deal cools.
What an SBOM is
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. It describes VEX as an attestation, a form of security advisory, that says whether products are affected by known vulnerabilities. A hospital asking for an SBOM usually wants to check its own exposure when a new flaw appears.
A five day plan
| Day | Task | Output |
|---|---|---|
| 1 | Ask what format and scope the hospital wants, and why | Written scope |
| 2 | Generate an SBOM from the build of the release they will run | Raw file |
| 3 | Review: missing components, wrong versions, internal packages | Corrected file |
| 4 | Decide what to share and under what terms | Sharing note |
| 5 | Send with a short cover note and offer a call | Delivered |
On day 1, ask the question. Often the real need is narrower than the request, such as "which components handle patient data" or "are you affected by a flaw we just read about." Answering that can be faster than sending a file.
Review checks before sending
- Does it include transitive components, not only direct ones?
- Does it cover the shipped artifact, such as the container image or installer, and not only source manifests?
- Are versions exact?
- Are internal package names or private repository paths exposed unintentionally?
- Is it dated, with the release identifier?
Build time generation from the artifact you ship is more reliable than generating from a source checkout. If you generated from source only, say so in the cover note.
Cover note wording
"Attached is the SBOM for release X, generated on this date from the build artifact. It lists direct and transitive components. It is an inventory, not a statement about vulnerabilities. If you need to know whether a specific advisory affects us, send it and we will reply with an assessment."
That last sentence sets up a useful routine: the hospital sends an advisory, you reply with an exposure statement.
What to avoid
- Claiming the SBOM proves the product is secure. It does not.
- Sending raw scan output alongside it with no explanation.
- Promising updates on a schedule you cannot keep. Commit to "per release" if that is true.
- Treating the request as legal or contractual advice territory. Check your contract and ask counsel about any obligation language.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an inventory entry contains, then check your own file for the same fields.
Safeguard can generate an SBOM from scans, and the free scan at gold.safeguard.sh/scan lets you see a first inventory before you commit to a format.
Quick check
Which SBOM format should we use?
Ask the hospital. The two common formats are widely supported, so pick whichever the reviewer's tools read.
Do we have to send it to every customer?
That depends on your contracts. Many vendors share on request under NDA. Check each agreement.
Sources
Last reviewed: 19 October 2026.
