A SaaS trust page should say whether you produce SBOMs for the service, what they cover, how often they update, and how customers request them. It should also state who is responsible for what, because SaaS risk is shared between producer and operator. Do not imply customers hold a copy of running software.
Why SaaS is different
CISA's 2026 minimum elements guidance says the shared responsibility between SaaS producers and operators, and the frequent changes to SaaS, complicate applying the SBOM model built for on-premises software. Both sides help administer and secure the system, which may limit some SBOM use cases. It also notes that delivering SBOMs at the pace of cloud releases could overwhelm both parties, and that distribution through APIs can capture snapshots as CI/CD pipelines change the code.
So a SaaS SBOM is a statement about a service at a point in time, not a file shipped with an installer.
What to write
Cover five points.
- Scope. Which services and components the SBOM covers, such as the application, its container images, and agents you ship to customers.
- Format. SPDX or CycloneDX, and the version. CISA names these as the two widely used formats.
- Frequency. Per release, per month, or on request. State what is true. The guidance expects each version or update to have an associated SBOM, and notes that SaaS frequency may need further specification.
- Delivery. Request form, portal, or API.
- Responsibility. What you maintain, and what the customer controls, such as their own integrations.
An example block
| Item | Statement |
|---|---|
| Scope | Web application and API services as of release date |
| Format | CycloneDX, version stated in file |
| Frequency | Updated with each production release |
| Delivery | Customer portal, on request |
| Contact | Security team address |
Replace each value with your real practice. If you do not produce SBOMs, say so and describe what you offer instead, such as a dependency summary or a component list for customer-installed parts.
Cover the pieces customers run
Many SaaS vendors also ship CLI tools, browser extensions, mobile apps, or on-premises connectors. Those are conventional software, and customers may well want SBOMs for them with each release. Treat them separately from the hosted service so the page does not blur two different cases.
Be careful with snapshots
If you give a snapshot, label it with its timestamp and the release it describes. CISA's SBOM Timestamp element records the date and time of the most recent update. A customer who reads a six-month-old snapshot as current will draw wrong conclusions, and so will their auditor.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how monitoring keeps inventory current after release, which is the gap a one-time SaaS snapshot leaves.
Where Safeguard fits
Safeguard's SBOM and dependency scanning supports per-release inventory, and its continuous approach keeps data current between releases. A free scan is at gold.safeguard.sh/scan.
Quick check
Does a SaaS company need to publish an SBOM?
Not necessarily. The guidance says SaaS needs more thought. Say clearly what you offer, and offer more detail on request.
How often should a SaaS SBOM update?
The guidance expects an SBOM for each version or update, and notes SaaS frequency may need more specification. Pick a cadence you can keep, and state it.
Sources
Last reviewed: 19 October 2026.
