SaaSFort In 2021, a logging library called Log4j turned into a global crisis overnight. Every enterprise IT team scrambled to answer one question: “Are any of our vendors using Log4j?”
Most couldn’t answer it in hours. Some took weeks. A few couldn’t answer it at all.
That gap — between what software vendors know about their own components and what their enterprise customers need to know — is exactly what the Software Bill of Materials (SBOM) is designed to close.
In 2026, SBOM is moving from “nice to have” to contractual requirement for B2B SaaS vendors targeting enterprise buyers.
What Is an SBOM?
An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in your software — similar to an ingredient list on food packaging, but for code.
A complete SBOM lists:
| Component Type | Examples |
|---|---|
| Open source libraries | lodash 4.17.21, express 4.18.2, numpy 1.24.3 |
| Third-party SDKs | Stripe SDK, Twilio SDK, Auth0 SDK |
| Build tools | Node.js version, Go compiler, Python runtime |
| Container base images | node:20-alpine, gcr.io/distroless/static |
| Transitive dependencies | Libraries your libraries depend on |
The critical value: when a new CVE is published (e.g., CVE-2024-XXXXX in axios), an enterprise buyer can query your SBOM and know immediately whether they’re exposed through your product.
Why SBOM Is Now a B2B SaaS Requirement
EU Cyber Resilience Act (CRA) — Regulation EU 2024/2847
The CRA entered into force in December 2024 and applies to all software products sold in the EU. Key SBOM-related obligations:
- Article 13: Manufacturers must “identify and document vulnerabilities and components” in their products
- Article 14: Actively exploited vulnerabilities must be reported to ENISA within 24 hours
- Annex I: Products must be “designed, developed and produced” with supply chain security practices
For SaaS vendors classified as “important” or “critical” products (cloud software, security tools, payment systems), SBOM generation is effectively mandatory by 2026.
Practical impact: If you sell to EU enterprises in regulated industries (financial services, healthcare, telecoms), expect SBOM requests in procurement questionnaires throughout 2025–2026.
US Executive Order 14028 — Cascading Commercial Effect
EO 14028 mandated SBOM for US federal government software suppliers. But the commercial cascade has been significant:
- US financial services firms now include SBOM clauses in vendor contracts
- Healthcare organizations request SBOMs under HIPAA vendor management requirements
- Defense contractors pass SBOM requirements down their supply chains
If you have any US enterprise customers, SBOM expectations have likely already reached your procurement pipeline.
Enterprise Risk Management Maturation
Beyond regulation, enterprise CISOs have simply gotten smarter about vendor risk. Modern TPRM (Third-Party Risk Management) programs now include:
- SBOM review as part of initial vendor onboarding
- Continuous SBOM updates as a contractual obligation
- CVE response time SLAs tied to SBOM visibility
SBOM Formats: SPDX vs CycloneDX
Two formats dominate. You need to support both:
| SPDX | CycloneDX | |
|---|---|---|
| Maintained by | Linux Foundation | OWASP |
| Format | JSON, RDF, YAML, tag-value | JSON, XML |
| Primary use | License compliance + security | Security + vulnerabilities |
| US government | Preferred by CISA/NIST | Accepted |
| Enterprise tooling | Broad support | Broader modern tooling support |
| VEX support | Via companion spec | Native |
Recommendation for SaaS vendors: Generate CycloneDX JSON (broader tooling, native VEX support for vulnerability exceptions) and offer SPDX on request.
SBOM Tooling: What to Use in 2026
Generation Tools
| Tool | Language/Ecosystem | Format | Free? |
|---|---|---|---|
| Syft (Anchore) | All (container + filesystem) | SPDX, CycloneDX | Yes |
| cdxgen | Node, Python, Java, Go, .NET | CycloneDX | Yes |
| trivy sbom | Containers, filesystems | SPDX, CycloneDX | Yes |
| github sbom API | GitHub repos | SPDX JSON | Yes (GitHub) |
| Snyk | 10+ languages | CycloneDX | Freemium |
| FOSSA | Enterprise | SPDX, CycloneDX | Paid |
Quickest start: syft . -o cyclonedx-json=sbom.json — scans your project directory and produces a CycloneDX JSON SBOM in seconds.
CI/CD Integration
# GitHub Actions — generate SBOM on every release
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
format: cyclonedx-json
output-file: sbom.cyclonedx.json
artifact-name: sbom
- name: Upload SBOM
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.cyclonedx.json
This produces a fresh SBOM on every build and stores it as a build artifact — satisfying the “automated generation” requirement that enterprise buyers look for.
Vulnerability Scanning Against SBOM
Once you have an SBOM, you can scan it for known CVEs:
# Trivy — scan SBOM for CVEs
trivy sbom sbom.cyclonedx.json --severity CRITICAL,HIGH
# Grype — vulnerability scanner from Anchore
grype sbom:sbom.cyclonedx.json
This becomes your early warning system: when a new CVE drops, you know within minutes whether you’re affected.
VEX: The SBOM Companion for Vendor Communication
An SBOM tells buyers what’s in your software. VEX (Vulnerability Exploitability eXchange) tells them what’s actually exploitable.
When a CVE is published for a component you use, you need to communicate:
- Affected: Your product is vulnerable and users are at risk
- Not affected: The CVE exists in your code but you’re not exploitable (e.g., vulnerable function never called)
- Fixed: Patch applied, version updated
- Under investigation: Analyzing impact, will update
VEX documents are attached to your SBOM and allow enterprise buyers to triage vendor risk accurately — rather than treating every CVE mention as a critical issue.
CycloneDX natively supports VEX. This is one reason CycloneDX is increasingly preferred in enterprise vendor assessments.
What Enterprise Buyers Actually Ask About SBOM
In DDQs and Security Questionnaires
| Question | What They Want to See |
|---|---|
| ”Do you maintain an SBOM?” | Yes — CycloneDX JSON, generated per build |
| ”How frequently is your SBOM updated?” | Every build (automated in CI/CD) |
| “Can you share your current SBOM?” | Yes — available on request under NDA |
| ”How do you track CVEs against your components?” | Automated CVE scanning (Trivy/Snyk) alerts within 24h |
| ”What is your CVE patching SLA?” | Critical: 24h. High: 7d. Medium: 30d. |
| ”Do you use VEX?” | For CycloneDX — increasingly expected by mature buyers |
During Procurement Negotiations
Enterprise legal teams are now adding SBOM clauses to vendor contracts:
- Obligation to provide SBOM within X days of signing
- Obligation to update SBOM quarterly or upon major release
- Right to audit SBOM accuracy
- CVE notification requirements (often 24–48h for critical)
If you’re in a large enterprise deal negotiation, expect to see these clauses in 2026.
Building Your SBOM Program: 4 Steps
Step 1: Generate Your First SBOM Today
# Install Syft
brew install syft
# Generate CycloneDX SBOM from your project
syft . -o cyclonedx-json > sbom-$(date +%Y%m%d).json
# Or for a container image
syft your-org/your-app:latest -o cyclonedx-json > sbom-container.json
Your first SBOM will reveal your full dependency tree — including transitive dependencies you didn’t know existed. This is often an eye-opener.
Step 2: Automate in CI/CD
Add SBOM generation to every build pipeline (see GitHub Actions example above). Store SBOMs as build artifacts with timestamps. This creates the audit trail enterprise buyers expect.
Step 3: Scan and Remediate
Run Grype or Trivy against your SBOM weekly. Set up alerts for Critical and High CVEs. Document your patching SLA in writing — this becomes evidence for security questionnaires.
Step 4: Define Your Sharing Policy
Decide in advance:
- Public SBOM: For open source projects or maximum transparency
- NDA-gated SBOM: Standard for enterprise B2B — share after NDA signing
- Summary only: Provide component count and CVE status without full SBOM
Most B2B SaaS vendors choose NDA-gated initially. Document this in your security posture documentation.
SBOM and Web Application Security
An SBOM documents what’s in your software supply chain. But enterprise buyers also evaluate what’s exposed from the outside — your running web application.
These are complementary security surfaces:
| What SBOM Covers | What Web App Scanning Covers |
|---|---|
| Open source dependency CVEs | Misconfigured security headers |
| Transitive dependency risks | OWASP Top 10 vulnerabilities |
| Build tool versions | API endpoint exposure |
| Container base image risks | SSL/TLS configuration |
| License compliance | Sensitive file exposure |
SaaSFort scans your running web application and APIs against OWASP Top 10, producing a deal-ready report you can share with enterprise buyers alongside your SBOM — giving them complete coverage of both the supply chain and runtime attack surface.
Key Takeaway
SBOM is no longer a compliance checkbox for government contractors. In 2026, it’s becoming a standard expectation in enterprise B2B SaaS procurement — driven by EU CRA, US federal requirements, and maturing CISO buying patterns.
The good news: generating your first SBOM takes 10 minutes with free tooling. Automating it in CI/CD takes an afternoon. The documentation and sharing policy takes another day.
What takes time is building the CVE response process and patching SLAs that make your SBOM meaningful — but that’s work worth doing regardless of buyer requirements.
Start today: Run syft . -o cyclonedx-json > sbom.json in your project directory. Then run a free SaaSFort scan to see what enterprise procurement teams see when they audit your running web application.
Sources: EU Cyber Resilience Act (Regulation EU 2024/2847), US Executive Order 14028 (May 2021), CISA SBOM guidance and minimum elements (July 2021), NIST SP 800-204D, OWASP CycloneDX specification v1.6, SPDX specification v2.3, Anchore Syft documentation.
Ready to put this into practice?
Run a free OWASP scan on your domain. First results in under an hour — no signup required.
Start Free Scan