SBOM Compliance for SaaS: What the EU CRA, PCI DSS 4.0, and NIS2 Now Require

Your SaaS product is an assembly of hundreds of components, including open-source libraries, third-party APIs, runtime frameworks, container base images, and AI models pulled from public repositories. When Log4Shell broke in December 2021, organizations that had no inventory of their software components spent days discovering whether they were exposed. Those with a Software Bill of Materials knew within hours.

That lesson has now become a regulatory mandate. As of 2026, three overlapping frameworks — the EU Cyber Resilience Act, PCI DSS 4.0, and NIS2 — require SaaS companies to produce, maintain, and, in some cases, share documented inventories of every software component in their products. The EU AI Act introduces a parallel obligation specifically for AI components. Forrester's March 2026 analysis is direct: "waiting for uniform policies is a losing strategy."

This guide covers what an SBOM is, which regulations now mandate it for SaaS, how it maps to the compliance frameworks your customers audit you against, and what a production-grade SBOM program looks like in practice.

What Is an SBOM — and Why Is SaaS Different?

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, dependency, and piece of metadata that makes up a software product. Think of it as the ingredient label on food packaging, except instead of listing flour and salt, it lists library names, versions, package URLs, dependency relationships, component hashes, and license identifiers.

CISA's definition is precise: an SBOM is "a nested inventory, a list of ingredients that make up software components." Nested is the critical word. Modern software dependencies are not flat. A single direct dependency may pull in dozens of transitive dependencies. An SBOM must capture all of them, direct and transitive, because vulnerabilities do not announce themselves only in packages you intentionally included.

SaaS introduces specific complications that make SBOM management harder than it is for packaged software:

Continuous deployment breaks point-in-time inventories. SaaS products deploy multiple times per week, sometimes per day. Dependencies change with every release. An SBOM generated at last quarter's audit and never updated does not reflect the software your customers are running today.

SaaS stacks are multi-layer. A SaaS application includes application code, containerized runtime environments, infrastructure-as-code dependencies, CI/CD pipeline tools, and increasingly AI models and APIs. Each layer has its own dependency graph. An application-layer SBOM that ignores the container base image or the AI inference library is materially incomplete.

Customer and regulatory expectations diverge. Enterprise buyers are already requesting SBOMs in procurement questionnaires. Federal agencies require them for any software in their supply chain. EU regulators are making it a legal obligation. The same SBOM needs to satisfy multiple audiences with different format expectations and different levels of required detail.

CISA published a paper specifically addressing the SaaS SBOM challenge, acknowledging that SaaS and non-SaaS software differ in key ways and framing SBOM transparency as valuable and achievable for SaaS providers despite those differences.

The Regulatory Mandates Hitting SaaS Now

EU Cyber Resilience Act — Deadlines in Force

The EU Cyber Resilience Act introduces mandatory cybersecurity requirements for products with digital elements. Manufacturers must have vulnerability and incident reporting in place by September 11, 2026, with requirements to produce and maintain SBOMs taking effect by December 27, 2027.

The CRA applies to any product with digital elements placed on the EU market, including SaaS platforms accessible to EU users. The law requires that SBOMs be provided in a "commonly used and machine-readable format," which means CycloneDX or SPDX. Market surveillance authorities can request SBOMs from manufacturers; the CRA defines an SBOM as "a formal record containing details and supply chain relationships of various components used in building software."

The September 2026 deadline for vulnerability reporting is less than four months away. Organizations without an SBOM cannot operationalize vulnerability reporting — you cannot report that a component is or is not affected by a disclosed CVE if you do not know what components your product contains.

PCI DSS 4.0 — Already Required Since March 2025

PCI DSS v4.0 Requirement 6.3.2 mandates that every instance of bespoke and custom software maintain an inventory of software components, which is fully required as of March 31, 2025. PCI DSS 4.0 does not use the term "SBOM," but the requirement is functionally identical. Every SaaS company that processes, transmits, or stores cardholder data is in scope.

Testing procedure 6.3.2. a makes clear that assessors expect to see a documented inventory and will verify it against the software in use. The SBOM must be actively used in your vulnerability management program — it is not enough to simply catalog components, you must track patch status and respond to known vulnerabilities.

The practical implication: if your QSA has not yet asked for your component inventory during a 2025 or 2026 PCI DSS assessment, they will. Any organization that built a one-time inventory rather than an automated, living SBOM is already out of compliance with the requirement's intent.

NIS2 Directive — Supply Chain Security Obligation

NIS2's supply chain risk management requirements apply to essential and important entities across critical sectors, including many B2B SaaS companies that provide services to healthcare, financial, energy, and infrastructure organizations. NIS2 mandates supply chain security for in-scope entities, and the implementing regulation (EU 2024/2690) creates explicit obligations around software component transparency. Without an SBOM, demonstrating supply chain security posture to an NIS2 auditor requires manual attestation that an SBOM-based program can provide automatically.

EU AI Act Annex IV — The AI-BOM Angle

The EU AI Act does not name "AIBOM" explicitly, but its technical documentation requirements in Annex IV align closely with emerging SPDX 3.0 AIBOM and CycloneDX ML-BOM specifications. Research published in 2026 shows SPDX 3.0 AIBOM satisfies 13 of 14 Annex IV obligations. High-risk AI providers must document datasets, model training, and software components, with August 2, 2026, as the main application date.

The OWASP Foundation and the CycloneDX AI/ML Working Group published the authoritative guide to AI/ML BOMs in March 2026 — the first edition of a framework specifically designed to inventory AI components, including model architecture, training data provenance, and inference dependencies. If your SaaS product uses AI models, your SBOM program needs to extend to cover them.

US Regulatory Baseline — EO 14028 and CISA 2025

US Executive Order 14028 and NTIA minimum elements set the baseline for federal supply chains. CISA's 2025 draft adds hash, license, and generation context fields. OMB Memorandum M-26-05 (January 2026) rescinded the mandatory attestation memos, shifting to an agency-led, risk-based approach — but EO 14028 itself remains in effect.

The 2025 CISA Minimum Elements Draft updates the 2021 NTIA guidance to add Component Hash, License Information, Tool Name, and Generation Context — moving SBOMs from a simple checklist of components toward verifiable, actionable intelligence.

For SaaS companies selling to US federal agencies or organizations in federal supply chains, SBOM provision is now a procurement expectation embedded in contract vehicles, not a future requirement.

How SBOM Maps to the Compliance Frameworks You're Already Operating Under

SaaS companies operating SOC 2 programs often miss that SBOM obligations exist within their current framework commitments. They are not new programs to build from scratch — they are gaps within programs already in scope.

SOC 2 — CC7.1 and CC6.8. The Change Management criteria require that you detect unauthorized software and that all components in your production environment are authorized and inventoried. An automated SBOM satisfies both by providing continuous visibility into what is deployed. CC7.1's security event monitoring obligation extends to detecting newly disclosed vulnerabilities in production components, which is operationally impossible without a component inventory. SBOM-integrated vulnerability scanning is how mature organizations operationalize CC7.1 for their dependency stack.

PCI DSS 4.0 — Requirement 6.3.2 and 11.3.1.1. Two controls functionally require a living, searchable SBOM. Requirement 6.3.2 mandates a component inventory for all bespoke and custom software. Requirement 11.3.1.1 requires that vulnerabilities be managed using a risk-ranked inventory, which only works if the inventory is complete and current.

NIST SP 800-53 — SA-12 and SA-15. The Supply Chain Protection (SA-12) and Development Process and Standards (SA-15) controls require documentation of software supply chain components and provenance. NIST SP 800-171 — which applies to organizations handling Controlled Unclassified Information — carries equivalent requirements under 3.14.1 and 3.14.3. Both are satisfied by a production-grade SBOM program.

ISO 27001:2022 — Annex A, Controls A. 5.20 (addressing information security in supplier agreements) and A.8.8 (management of technical vulnerabilities) both benefit directly from SBOM integration. A.8.8 requires that you identify and remediate technical vulnerabilities — SBOM-VEX integration is the mechanism that scales this to modern dependency stacks.

DORA — ICT Third-Party Risk Register. DORA requires financial entities to maintain up-to-date information on all ICT dependencies. SBOM data is the structured mechanism for satisfying this obligation at the component level, particularly for SaaS vendors supplying financial institutions who have their own DORA compliance to demonstrate.

CycloneDX vs. SPDX: Which Format Does Your Compliance Program Need?

This is the question most SaaS teams get wrong first — they pick a format based on which tool generated it rather than which use case they need to satisfy. The three primary SBOM standards serve different purposes: CycloneDX prioritizes vulnerability tracking with native VEX support; SPDX focuses on licensing compliance and has broader tool adoption; SWID is an IT asset management format required for some federal systems but rarely used elsewhere.

For SaaS compliance in 2026, the practical guidance is:

Use CycloneDX when your primary driver is security and vulnerability management. CycloneDX has native VEX (Vulnerability Exploitability eXchange) support, which allows you to declare whether your code actually calls a vulnerable function — not just whether you include a vulnerable package. This distinction matters enormously for PCI DSS 4.0 compliance and for EU CRA vulnerability reporting. CycloneDX 1.7 also supports the ML-BOM profile for AI/ML systems, as outlined in the OWASP authoritative guide.

Use SPDX when your primary driver is licensing compliance and open-source governance. SPDX 3.0's AIBOM profile satisfies 13 of 14 EU AI Act Annex IV technical documentation obligations. If your product contains AI components and you have EU customers or are subject to the EU AI Act, SPDX 3.0 with the AIBOM profile is your most efficient path to Annex IV compliance.

The practical answer for most SaaS teams: generate both. Both formats are accepted by the EU CRA, EU AI Act, PCI DSS, and US federal frameworks. Most modern SBOM generation tooling (Syft, CycloneDX CLI, SPDX tools) can output both from the same dependency scan. Store both in your artifact repository and share the format each recipient requests. Both CycloneDX and SPDX are widely accepted — the EU CRA requires "a commonly used and machine-readable format," and both formats meet that requirement.

What a Production-Grade SBOM Program Looks Like for SaaS

A single SBOM generated manually before an audit is not a program. It is a point-in-time snapshot that is stale by the next deployment. A production-grade SBOM program has four operational components that distinguish it from a compliance checkbox.

1. Automated Generation in CI/CD

Every build pipeline should automatically generate an SBOM at build time using a tool such as Syft, the CycloneDX CLI, or OWASP Dependency-Track. The SBOM should be attached to the build artifact and versioned alongside the release. This means every deployed version of your software has a corresponding SBOM — and you can produce the exact SBOM for any version currently running in any customer environment on demand.

Automation is essential because manual processes cannot keep pace with today's development cycles or the scale of modern environments. Automation keeps SBOMs up to date and builds security and compliance directly into CI/CD pipelines.

2. Vulnerability Correlation with VEX

An SBOM without vulnerability correlation is a list. An SBOM integrated with a vulnerability database — connected to CVE feeds, OSV, and the GitHub Advisory Database — is an active risk-management tool. Configure your SBOM tooling to automatically flag components with known CVEs and produce VEX documents that declare your exploitability status for each finding.

This mechanism satisfies PCI DSS 4.0 Requirement 11.3.1.1 (vulnerability management based on a risk-ranked inventory) and EU CRA vulnerability reporting. It also dramatically accelerates your SOC 2 CC7.1 evidence production — instead of manually reviewing security advisories, your pipeline automatically flags affected components.

3. Multi-Layer Scope Coverage

For SaaS, the SBOM scope must cover every layer of your stack:

• Application layer: all direct and transitive dependencies in your application code

• Container layer: base image components, installed packages, and runtime dependencies inside every container your product ships

• AI/ML layer: model names, versions, providers, training data lineage (where available), and inference libraries for any AI components — using CycloneDX ML-BOM or SPDX 3.0 AIBOM format

• Infrastructure layer: infrastructure-as-code dependencies and provider SDKs that affect your production environment

Scoping only the application layer leaves your container base images — often the source of the highest-severity CVEs in a SaaS stack — completely outside your compliance coverage.

4. Distribution and Sharing Infrastructure

Enterprises are prioritizing secure software development and SBOMs in procurement, often including SBOM requirements in RFIs or contracts to demand transparency from vendors. Your program needs a defined process for sharing SBOMs with customers and regulators that does not involve emailing flat files.

Options include: a customer-accessible SBOM portal (secure, versioned, access-controlled), automated SBOM delivery as part of your security documentation package, and container registry integration for container-layer SBOMs via OCI artifact storage. Define your sharing process before your first enterprise customer asks for it — reactive SBOM delivery creates version confusion and audit liability.

What to Do in the Next 30 / 60 / 90 Days

Days 1–14 — Inventory your current state. List every application, container image, and AI component your SaaS product ships. For each, document whether an SBOM currently exists, in what format, and when it was last generated. Most teams discover that SBOMs exist for some application-layer components but not for container images or AI dependencies. That gap is your starting scope.

Days 15–30 — Instrument one build pipeline. Pick your highest-risk or most customer-visible service and instrument its CI/CD pipeline to auto-generate a CycloneDX SBOM on every build using Syft or an equivalent tool. Validate the output against NTIA minimum elements and CISA 2025 draft fields. This gives you a working proof of concept and your first audit-ready SBOM before your next assessment cycle.

Days 31–60 — Connect vulnerability correlation and expand scope. Integrate your SBOM pipeline with a vulnerability database (Grype, Trivy, or OWASP Dependency-Track). Configure alerts for new CVEs affecting components in your inventory. Expand SBOM generation to cover container-based images and AI model components. Establish a central SBOM storage location with versioning tied to release tags.

Days 61–90 — Map to compliance frameworks and build sharing infrastructure. Document how your SBOM program satisfies each relevant framework control: PCI DSS 6.3.2, SOC 2 CC7.1, EU CRA Article requirements, and NIST SA-12. Create a customer-facing SBOM sharing process. If you have EU AI Act exposure, produce your first ML-BOM for any AI components using CycloneDX 1.7 ML-BOM profile. Review your next QSA or SOC 2 audit engagement and add SBOM evidence to your evidence collection plan.

Frequently Asked Questions

What is an SBOM, and why does my SaaS company need one? An SBOM is a machine-readable inventory of every software component inside your product — libraries, frameworks, APIs, container dependencies, and AI models. SaaS companies need them because EU CRA, PCI DSS 4.0, NIS2, and the EU AI Act now mandate component transparency. Enterprise customers are also requiring SBOMs in procurement. Organizations without one cannot respond to vulnerability disclosures quickly or satisfy supply chain security audits.

What is the difference between CycloneDX and SPDX? CycloneDX is built for security and vulnerability management, with native VEX support — making it well-suited for PCI DSS 4.0 compliance and EU CRA vulnerability reporting. SPDX is built for open-source license compliance and has broader tool adoption — the AIBOM profile in SPDX 3.0 satisfies 13 of 14 EU AI Act Annex IV technical documentation obligations. Both formats are accepted by the EU CRA and most regulatory frameworks. Most SaaS teams should generate both.

Does SOC 2 require an SBOM? SOC 2 does not use the term "SBOM," but Change Management criteria CC6.8 and Security Event Monitoring criteria CC7.1 both create obligations that an automated SBOM program satisfies. Specifically, CC7.1 requires detection of vulnerabilities in system components, which is operationally impossible without a component inventory connected to vulnerability feeds.

When does the EU Cyber Resilience Act require SBOMs? The CRA requires vulnerability and incident reporting by September 11, 2026. The obligation to produce and maintain SBOMs takes effect December 27, 2027. However, the vulnerability reporting requirement cannot be met without knowing which components your product contains — which means the functional SBOM requirement is due by September 2026, not December 2027.

What is an AI BOM, and do I need one? An AI Bill of Materials (AI-BOM or ML-BOM) is an SBOM extended to cover AI and machine learning components — model names, versions, providers, training data provenance, and inference dependencies. The EU AI Act Annex IV technical documentation requirements for high-risk AI systems align closely with the SPDX 3.0 AIBOM and CycloneDX ML-BOM specifications. If your SaaS product uses AI models, your SBOM program should include an AI-BOM component.

Build Your SBOM Program Before September 2026

Waiting for uniform policies is a losing strategy — agility and readiness are now competitive differentiators. The EU CRA vulnerability reporting deadline is less than four months away. PCI DSS 4.0 Requirement 6.3.2 has been a scored requirement since March 2025. Enterprise buyers are already writing SBOM requirements into procurement contracts. The organizations that build automated, multi-layer SBOM programs now will enter their next audit cycle with evidence that their competitors cannot match.

The path is not complicated — it is automation, scope completeness, vulnerability integration, and a sharing infrastructure. The organizations failing on SBOM compliance are not failing because the technology is hard. They are failing because they are treating it as a future initiative rather than a current one.

DSALTA's AI compliance platform connects your SBOM evidence directly to your SOC 2, ISO 27001, PCI DSS, and EU AI Act control frameworks — so your component inventory automatically drives your compliance posture, not manually.