Software bill of materials (SBOM) for SaaS: create and use one
Create an artifact-matched SBOM for a SaaS release, choose an interoperable format, capture component context and use the inventory to assess new vulnerabilities.
In this guide
What is an SBOM, and what does it tell a SaaS team?
A software bill of materials (SBOM) is a structured inventory of software components and related information in a product. It can help a SaaS team identify affected dependencies when a vulnerability or licence question appears and help a customer understand what is in a delivered artifact. An SBOM is only as useful as its coverage, accuracy, freshness and connection to the exact product version; it is not a security certificate or proof that software is safe.
Choose the product and build stage the SBOM describes
A source-level inventory can describe declared dependencies before a build; a build-time SBOM can reflect components used to create an artifact; a post-build inventory can inspect what is packaged. Document which stage produced the file and which runtime, operating-system and bundled components are included. For a containerized SaaS release, tie the inventory to the image digest and release version.
Use a machine-readable format accepted by your consumers
SPDX and CycloneDX are widely used, interoperable SBOM formats. Ask customers and your tooling which versions and fields they can ingest; validate the generated document against its format. Do not create a custom export when an established format meets the use case, and record the format version so future tools can interpret it.
Record component identity and generation context
Include the product or artifact identity, version, supplier or author information, component names and versions, relationships, generation time and tool or method where available. Capture direct and transitive dependencies and disclose known gaps such as dynamically downloaded modules or components that could not be identified. An incomplete inventory should say what it does not cover.
| Release / image digest | Format and version | Build stage and scope | Known gaps / validation | Owner and delivery location |
|---|---|---|---|---|
How should a SaaS provider generate and deliver an SBOM?
Generate the SBOM from the release process
Automate generation from the dependency lockfiles, build inputs and final package or image, then validate that the SBOM describes the artifact being released. Keep the SBOM alongside release metadata and record a digest or other binding that connects the file to the artifact. A manually maintained spreadsheet will drift as dependencies change.
Protect integrity and choose a suitable sharing channel
Deliver the SBOM through a stable authenticated release channel or customer portal and make clear which product version it covers. Use signed release metadata or attestations when available to help recipients verify origin and integrity. Do not publish sensitive build paths, internal component details or customer-specific information unless disclosure is intended.
Set an owner and update cadence
Generate a new SBOM for each materially different release and rebuild it when dependencies or packaging change. Assign an owner for format validation, customer questions, vulnerability matching and retention. Customers should be able to identify which SBOM is current without relying on an undocumented email attachment.
How do teams use an SBOM during vulnerability response?
Match a vulnerability to exact component versions and product releases
When an advisory appears, query SBOM inventories for the affected package, version and relationship to shipped services. Check whether the component is actually present in the affected runtime or image and whether the vulnerable code path is reachable. Keep asset exposure and active-exploitation evidence in the wider risk decision; an SBOM speeds discovery but does not decide remediation by itself.
Track false positives, missing data and remediation evidence
Component names can be ambiguous and version ranges can be misinterpreted. Confirm matches with package and build records, record why a finding is affected or not affected, and update the SBOM after a fix is released. Link the component finding to the vulnerability-management record and preserve the evidence used to close it.
Use SBOMs to improve supplier and release transparency
A customer can request the format, scope, update frequency, vulnerability notification route and artifact binding that fit its risk. A provider can explain where SBOM coverage is incomplete and how it handles a newly disclosed component issue. An SBOM does not replace security testing, provenance, vulnerability disclosure or a supported patch process.
SBOM questions for SaaS teams and customers
Does an SBOM prove that a SaaS product has no vulnerabilities?
No. It lists components and related facts within a stated scope. It may be incomplete, and a clean component list says nothing by itself about custom code, configuration, access control or runtime exposure. Use it as an input to security work, not a pass/fail certificate.
Which SBOM format should we request?
SPDX and CycloneDX are established machine-readable options. Choose a format and version your tools can validate and consume, then state the fields and scope you need. Interoperability and freshness matter more than a format name alone.
How often should the SBOM be refreshed?
Refresh it for each release or artifact whose component composition changes, and ensure the customer can identify which release it describes. A live SaaS service may deploy many versions or regions, so connect the SBOM to a release or image digest and update the inventory when deployment changes.
Should a provider publish every SBOM publicly?
Not necessarily. The right channel depends on product design, customer commitments and whether the inventory exposes sensitive implementation details. Provide authorized customers a reliable way to obtain the relevant SBOM while keeping its integrity and access controls clear.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- CISA: Minimum Elements for a Software Bill of Materials (2025)Cybersecurity and Infrastructure Security Agency
- NIST SP 800-204D: Software Supply Chain Security in DevSecOps CI/CD PipelinesNational Institute of Standards and Technology
- SPDX Specifications: Software Bill of Materials standardSPDX Project, The Linux Foundation