Sometimes. Send SBOMs you already created at release time. For older versions without one, you may be able to regenerate from preserved source or artifacts, but label the result as generated later and say which data is unavailable. Do not backfill and imply it was created at release.
Why customers ask
A customer running version 2.3 of your product cannot use an SBOM for version 4.2. Some customers also ask for the whole history to trace when a component entered the product. The CISA 2026 minimum elements say each software version or update should have an associated SBOM, so the ask follows the guidance, even when your past practice did not.
What you might have
| Situation | What to send |
|---|---|
| SBOM stored at release time | The original file, unchanged |
| Source and lockfiles preserved | A regenerated SBOM, labelled with the date and context |
| Only the shipped artifact preserved | An SBOM from analysing the artifact, labelled as after build |
| Neither preserved | A plain statement that none can be produced |
Be honest about regeneration
An SBOM made today for a release from two years ago is a different thing from one made at release. Package registries change, tooling improves and lockfiles may be missing. The CISA text asks for an SBOM timestamp and a generation context, which together tell the reader when and how the file was made. Use both.
The context matters because component data differs by phase. The CISA text gives an example: an SBOM generated from source could be marked as before build, and binary analysis tools can generate one after build. Say which you used.
Never edit the timestamp to match the release date. The timestamp is defined as the record of the most recent update to the SBOM data, and each version of an SBOM gets a new one.
Set a boundary
You do not owe an unlimited archive. Offer a clear policy, such as supported versions only, and say so. If your support period has ended for a version, say that too. For related wording, see support periods and end of life dates.
Steps to answer the request
- List the versions the customer runs now. Start there, not with history.
- Check what you stored for each. Look in the release archive and the build logs.
- Regenerate only where inputs survive, and mark each file as generated later.
- Write a cover note that lists which files are original and which are regenerated.
- State the gaps. For versions with nothing, say none exists.
Going forward
Store an SBOM at every release, next to the artifact, with its hash. That turns the next request into a lookup. See archive SBOMs and provenance for every release.
Quick check
Can we back date a regenerated SBOM?
No. The timestamp records the most recent update to the SBOM data, so it should show when you generated it.
What if the customer insists on an SBOM for an unsupported version?
Explain what you can and cannot produce, and send what you have with its limits stated. Do not invent data.
Safeguard's SBOM and dependency scanning can help you produce an inventory at each release going forward, and the free scan shows what one looks like.
Sources
Last reviewed: 19 October 2026.
