The executive order on cybersecurity (EO 14028) kicked off the SBOM movement with a focus on software sold to the federal government. Initially, this seemed relevant only to vendors shipping traditional software -- on-premises installations, firmware, and packaged applications. SaaS vendors assumed they were exempt because customers do not install anything.
That assumption is evaporating. Enterprise customers, especially in financial services, healthcare, and government, are now including SBOM requirements in SaaS procurement questionnaires. The logic is sound: even though you do not install SaaS software, you depend on it. If a SaaS vendor is running a vulnerable version of Log4j, their customers are affected whether or not they can see the vulnerability.
What SaaS Customers Are Asking For
Customer requests fall into several categories:
Component inventory. What open-source and third-party components does your SaaS product use? This is the basic SBOM request.
Vulnerability status. Are there known vulnerabilities in your components, and if so, what is your remediation timeline?
Dependency update cadence. How quickly do you patch vulnerable dependencies after disclosure?
License compliance. What open-source licenses are present in your stack? Are there any copyleft licenses that could affect the customer?
Build provenance. Can you demonstrate that your deployed code was built from a verified source through a secured build pipeline?
The SaaS SBOM Challenge
SaaS SBOMs are fundamentally different from traditional software SBOMs.
Continuous deployment changes the SBOM constantly. A traditional software product has a release version with a static SBOM. A SaaS product deployed via continuous deployment may update multiple times per day. The SBOM that was accurate this morning may be outdated by afternoon.
The deployment environment is part of the bill of materials. A SaaS SBOM is not just your application code and its dependencies. It includes the operating system, runtime environment, container base images, cloud services, and infrastructure components.
You cannot share everything. A full SBOM of a SaaS product reveals your technology stack, which you may consider competitive intelligence. You need to balance transparency with protection of proprietary information.
What to Include in a SaaS SBOM
Application dependencies. The open-source and third-party libraries your application directly and transitively depends on. This is the minimum viable SBOM.
Runtime components. Language runtime versions (Node.js, Python, Java), container base images, and operating system versions.
Known vulnerability status. For each component, whether there are known vulnerabilities and your remediation status.
Update timestamps. When the SBOM was generated and when the components were last updated.
What NOT to include: Internal service architectures, proprietary algorithm details, infrastructure topology, and security tool configurations. These are not relevant to the customer SBOM request and would expose competitive and security-sensitive information.
Automation Is Essential
Generating SaaS SBOMs manually is impractical given continuous deployment cadences. The SBOM must be generated automatically as part of your CI/CD pipeline.
Build-time SBOM generation. Integrate SBOM generation (using tools like Syft, Trivy, or your SCA platform) into your build pipeline. Generate a new SBOM with every deployment.
SBOM versioning. Tag each SBOM with the deployment version, timestamp, and environment. Store SBOMs with the same retention policy as your deployment artifacts.
Customer portal. Provide customers with a self-service portal where they can access the current SBOM and historical versions. This reduces the manual effort of responding to individual customer requests.
Automated vulnerability correlation. When a new CVE is published, automatically correlate it against your current SBOM and notify affected customers if necessary.
Responding to Customer Questionnaires
Enterprise procurement questionnaires about SBOMs are becoming standard. Prepare template responses for common questions:
"Do you maintain an SBOM?" Yes, generated automatically with every deployment.
"Can you provide your SBOM?" Yes, in CycloneDX or SPDX format, available through our customer portal.
"How quickly do you patch critical vulnerabilities?" Provide your SLA (e.g., critical within 24 hours, high within 7 days).
"Do you have any components with known unpatched vulnerabilities?" Provide the current status, including any accepted risks with justification.
How Safeguard.sh Helps
Safeguard.sh automates SBOM generation for SaaS products, integrating seamlessly with your CI/CD pipeline. Our platform generates SBOMs in CycloneDX and SPDX formats, correlates vulnerabilities automatically, and provides customer-facing dashboards for SBOM access. When enterprise customers ask about your software supply chain, Safeguard.sh gives you the data and tools to respond confidently.