Share the SBOM for the release the customer actually runs, because that is the software their risk depends on. Send the latest release's SBOM separately if they are planning an upgrade, and label each file with the product version it describes and the date it was generated.
Why the deployed release matters most
A customer's question is almost always, "Am I exposed?" That depends on the code in their environment today, not on what you shipped last week. If you hand over the latest SBOM to a customer on an older version, the answer may look better than reality, and a later incident will show the gap.
That is why mapping customers to the release they run is a core part of safe sharing.
Three cases
| Customer situation | What to share |
|---|---|
| Runs a managed SaaS you update continuously | Current production SBOM, with its generation date |
| Runs a self hosted version, pinned | SBOM for their pinned version, plus latest for upgrade planning |
| Evaluating, not yet deployed | SBOM for the version they will receive |
For SaaS, one current file is fine, but it ages quickly. Say when it was generated and how often you refresh it.
Steps to keep the mapping honest
- Record each customer's version wherever you track accounts, and update it when they upgrade.
- Archive an SBOM for every supported release. If you cannot reproduce the old one, you cannot answer for it.
- Name files by version. See version numbers for shared SBOMs.
- State the scope in the cover note. For example: "This SBOM describes release 4.9.2. The latest release is 4.12.0, SBOM attached separately."
- Refresh on a schedule. See how often to refresh an SBOM you share with customers.
What if the release is out of support?
If a customer runs a version you no longer support, share what you have but say so plainly. Note that no security fixes are issued for that version, and suggest an upgrade path. Do not quietly share the latest SBOM to make the picture look cleaner.
Layered products
Many products have more than one artefact: a server, a client, a container image, plugins. Provide one SBOM per deliverable or a clearly structured combined one, so the customer can match each to what they deployed. Mixing them in a single file without labels makes analysis harder.
Try it yourself
Continuous monitoring shows how the picture changes as new vulnerabilities appear against a fixed set of components. Watch how the same inventory produces different findings over time, which is why the version and date on a shared SBOM matter.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning produces an inventory for each build, so older releases keep their own record. A free scan shows how.
Quick check
Can one SBOM cover several versions?
It is cleaner to issue one per version. If you must combine, label each component set with the version it belongs to.
What if you cannot regenerate an old release's SBOM?
Say so, share the best record you have with its limits stated, and start archiving going forward.
Last reviewed: 19 October 2026.
