A SaaS startup still has an SBOM story, because the hosted service is built from open source and third party components too. Scope the SBOM to the code you deploy, say clearly that customers never receive the artifacts, and describe how often it changes as you release continuously.
Why SaaS buyers still ask
It is easy to assume an SBOM only matters for software someone installs. The CISA 2026 minimum elements guidance says the minimum elements apply to all software, while noting that some software types, such as software as a service in cloud environments, may need additional elements beyond them (see Sources). So the question is fair, and a reviewer may simply want to know what your service is built from.
For a buyer, the practical worry is the same as for shipped software: if a library behind your service is exploited, are they exposed?
Decide what the SBOM covers
A hosted product has several layers. Be explicit about which ones your SBOM describes.
- Application code. Dependencies from your lockfiles for each service.
- Container images. Base images and OS packages, if you deploy containers.
- Build and infrastructure tooling. Usually described separately, if at all.
- Third party services. Payment, email and similar vendors are suppliers, not components in your SBOM.
State the scope in one sentence: "Our SBOM covers the application dependencies and container images for the production API and web front end."
Handle continuous deployment honestly
If you deploy many times a day, you cannot hand over one SBOM per deploy by email. CISA's guidance says each software version or update should have an associated SBOM, and that a revised one should be issued when new details emerge. For a SaaS team, that usually means generating on each release in CI and keeping the history.
When a customer asks for "the" SBOM, offer the one for the currently deployed production version, with its timestamp, and explain that it is regenerated on release.
Sharing options
The same guidance says SBOMs should be available promptly to those who need them, and that access controls may limit sharing with unauthorized parties but should not block sharing between authorized parties. Reasonable options for a SaaS vendor:
- Send a point in time file under your agreement's confidentiality terms.
- Provide a link in a customer portal.
- Describe your process and let a reviewer inspect it on a call.
Pick the one you can sustain. Do not offer a live feed you have not built.
Words to use
"Our customers do not install our software, so the SBOM describes the components in our production environment at a point in time. We regenerate it on each release and can send the version currently deployed."
Words to avoid
Avoid "we have no third party code." Avoid "there is nothing to scan because it is SaaS." Both are easy to disprove and damage trust.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning for repositories and container images, and reachability analysis to help separate exposed findings from noise. A free scan shows what the output looks like.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how image layers and OS packages show up beside application packages, since a SaaS SBOM often needs both.
Quick check
Is a SaaS company required to provide an SBOM?
That depends on the contract and the buyer, so check your agreements. The guidance describes what an SBOM should contain, not who must supply one.
Do I list my cloud provider in the SBOM?
Usually not. Cloud and SaaS suppliers are better handled in your vendor list. The SBOM focuses on components in the software you build and deploy.
Sources
Last reviewed: 19 October 2026.
