A Software Bill of Materials (SBOM) is a machine-readable list of every software component in your application: open-source libraries, frameworks, dependencies, transitive dependencies, container images, base layers. Enterprise customers and auditors increasingly request it as supply-chain security evidence. The two standard formats are CycloneDX (OWASP project, security-focused) and SPDX (Linux Foundation, license-focused). Free tools to generate at startup scale: Syft, Trivy, GitHub Dependency Graph. For Indian SaaS startups, SBOM becomes a real obligation when you sell to US federal customers (Executive Order 14028, May 2021), large global enterprises, or Indian banks under RBI cybersecurity directives. This post walks when to generate, what tools to use, and how to maintain SBOMs at Series A scale.
Why this question matters now
In 2024 and 2025, SBOM moved from “academic supply-chain idea” to “row in your customer’s security questionnaire.” Three things drove it: the US Executive Order 14028 on Improving the Nation’s Cybersecurity (May 2021) made SBOMs a federal procurement requirement; the SolarWinds, Log4j, and 3CX supply-chain incidents demonstrated the operational need; and large enterprise vendor risk programs picked up SBOM as a standard evidence ask.
For an Indian SaaS startup selling to US enterprise customers in 2026, expect to see SBOM in vendor security questionnaires. For startups selling primarily to Indian SMB or mid-market, the requirement is rarer but increasing.
The good news: generating SBOMs is essentially free. The cost is operational: integrating it into your release pipeline and acting on the data.
What an SBOM actually contains
A useful SBOM lists, for every software component:
- Component name (e.g.,
lodash,requests,tensorflow) - Version (
4.17.21,2.31.0) - Source (npm, PyPI, Maven Central, your own GitHub)
- License (MIT, Apache-2.0, GPL-3.0)
- Hash for verification (SHA-256 typical)
- Supplier (organization or individual maintainer)
- Dependency relationship (direct dependency vs transitive dependency vs build-time only)
Modern formats also include:
- Vulnerabilities known to apply to that version (CVE references)
- Whether the component is included or excluded from the running build
- Container layer attribution (which base image contributed which component)
The output is a JSON or XML file (sometimes YAML) that machines can parse. Length: thousands of entries for any non-trivial SaaS application.
When customers and auditors ask for SBOM
The asks are increasing in frequency. Common triggers:
| Trigger | What’s asked |
|---|---|
| US enterprise security questionnaire | ”Provide your latest SBOM in CycloneDX or SPDX format” |
| US federal procurement (or SaaS sold to firms with federal contracts) | SBOM mandatory per EO 14028 and follow-on NTIA guidance |
| SOC 2 audit (newer auditors) | “Describe how you track and manage open-source dependencies”; SBOM is the answer |
| ISO 27001 audit | A.14.2 (security in development), A.15.1 (supplier security); SBOM strengthens evidence |
| Indian bank or RBI-regulated entity | Increasingly part of third-party risk assessment |
| DPDP Act compliance | Indirectly: data processor inventory may map to SBOM components handling personal data |
| Open source supply chain incident | Customer asks “are you affected by Log4Shell / Spring4Shell / etc.?”. SBOM lets you answer in minutes |
If none of these apply to your business yet, defer SBOM until a customer specifically asks. Premature investment.
Two standard formats: CycloneDX vs SPDX
CycloneDX
Maintained by OWASP. Designed for security use cases. Includes:
- Vulnerability data integration (VEX, Vulnerability Exploitability eXchange)
- Service inventory (microservices, internal APIs)
- License tracking
- Composition analysis
Best for: vendor risk assessments, supply-chain security programs, compliance reporting where security context matters.
SPDX
Maintained by Linux Foundation. Older standard (2010). Designed primarily for license compliance. Now ISO/IEC 5962:2021 standard.
Best for: open-source license auditing, US federal procurement (SPDX is explicitly mentioned in NTIA SBOM minimum elements), compliance programs that need ISO standardization.
Which to use
Generate both. Modern tools produce both formats from the same source data. Deliver whichever the customer asks for.
Tools to generate SBOMs
Free / open source (cover startup-scale needs)
| Tool | What it does | Best for |
|---|---|---|
| Syft | Generates SBOMs from container images, filesystems, source directories. Outputs CycloneDX, SPDX, GitHub format, table format. | Most common starting tool. Fast, no setup. |
| Trivy | SBOM generation plus vulnerability scanning. Container, filesystem, repository scanning. CycloneDX + SPDX output. | Combined SBOM + vulnerability scanning workflow. |
| GitHub Dependency Graph | Auto-generates basic dependency inventory for any GitHub-hosted repo. Free for public + private repos. | Zero-setup baseline. Good as starting point. |
| CycloneDX language tools | Language-specific generators: cyclonedx-npm, cyclonedx-python, cyclonedx-go, cyclonedx-maven-plugin | When you need language-native dependency resolution beyond what Syft sees |
| OWASP Dependency-Track | Receives SBOMs, tracks vulnerabilities over time, alerts on changes | When you have multiple components and want continuous tracking |
Paid tools (add policy enforcement, integration)
| Tool | Strength | Indicative pricing |
|---|---|---|
| Snyk SBOM (part of Snyk Open Source) | Integration with Snyk vulnerability platform, license policy | Pricing in the mid-range commercial SCA tier |
| JFrog Xray | Artifact repository integration if already using JFrog | Higher commercial tier |
| Sonatype Lifecycle | Mature policy engine, large-org workflows | Higher commercial tier |
| Anchore Enterprise | Container-focused with policy | Mid-to-higher commercial tier |
| Mend (formerly WhiteSource) | License + vulnerability management | Higher commercial tier |
For Series A SaaS startups, free tools cover ~80 percent of needs. Defer paid tooling until specific use cases (license policy enforcement, large-org workflow integration) justify the spend.
How to maintain SBOMs as code changes
The single biggest mistake: generate SBOM once for an audit, then forget. Dependencies update weekly; the audit-time SBOM is stale within a sprint.
The fix: generate SBOM on every production build, automatically.
# Example CI step (GitHub Actions, simplified)
- name: Generate SBOM
run: syft . -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.json
- name: Upload SBOM as release artifact
uses: actions/upload-artifact@v4
with:
name: sbom-${{ github.sha }}
path: sbom.*.jsonTime cost: seconds per build. Storage cost: trivial (a few KB to a few MB per SBOM).
For organizations with mature ops:
- Send each generated SBOM to OWASP Dependency-Track for continuous vulnerability tracking
- Subscribe to vulnerability feeds (CISA KEV, GitHub Advisory Database) to alert when new CVEs apply to your tracked components
For startups: store SBOMs as build artifacts, surface them on demand.
What to do when an SBOM finds a vulnerable dependency
The SBOM itself does not fix anything; it makes the situation visible. The action sequence:
- Check exploitability: is the vulnerable function actually called by your code? Many CVEs are theoretical for your specific use case
- Check if a patched version exists: look up the CVE on GitHub Advisory or NVD; identify the patched version
- Update the dependency (patch version if non-breaking, minor or major if needed; test thoroughly for breaking changes)
- Re-generate SBOM to verify the dependency is now patched
- Notify customers if you previously delivered an SBOM showing the vulnerable version (transparency builds trust)
For dependencies you cannot easily update (transitive dependency, end-of-life upstream): document the risk and any compensating controls, retain in SBOM with status annotation.
Decision matrix per stage
| Stage / situation | SBOM action |
|---|---|
| Pre-seed / Seed | Skip until first customer asks. Use GitHub Dependency Graph (free, automatic) for basic inventory awareness |
| Series A, US enterprise customers asking | Generate SBOM on every production build via Syft or Trivy. Store as release artifact. Deliver on customer request. |
| Series A, Indian customers only | Generate SBOM ad-hoc when asked. Defer continuous integration until volume justifies. |
| Series A pursuing SOC 2 or ISO 27001 | Generate SBOM as audit evidence. Mention in your security policy. |
| Series B+ | Continuous SBOM generation + vulnerability tracking via OWASP Dependency-Track or paid platform. Policy enforcement. |
| Federal customer or sub-contractor | Mandatory per EO 14028. Both CycloneDX and SPDX formats. Continuous generation. |
What we recommend in our engagements
We work with AI-first and API-first SaaS startups, Seed to Series B, primarily based in Bengaluru. The pattern in our audit and compliance and security consulting engagements:
- For Series A clients with US enterprise customer pipelines: install Syft or Trivy in CI within 30 minutes during scoping. Generate SBOM on every build. Cost: zero.
- For clients pursuing SOC 2 or ISO 27001: include SBOM generation in the policy evidence package. Reference it in supplier security and development security control implementations.
- For clients facing a specific incident (Log4Shell-style supply chain disclosure): SBOM-based affected-version search becomes triage-critical.
The most common mistake we see: founder generates a one-off SBOM for an audit, ships the audit, never integrates it into the build pipeline. Six months later the SBOM is stale and useless.
Where to go from here
If your enterprise customer just sent a security questionnaire asking for an SBOM and you do not have one, book a 30-min call with Ashok to scope what fits your stack. Or Security on Demand (INR 9,999, fully refundable) for a four-hour founder-led session that covers SBOM generation, integration into your CI, and walking through your customer’s specific question.
Related: SOC 2 vs ISO 27001 vs DPDP: Which Compliance First?, Vanta vs Drata vs Manual SOC 2, DPDP Act Compliance Checklist for SaaS Startups.
Frequently asked questions
What is a Software Bill of Materials and why does it matter?
A Software Bill of Materials (SBOM) is a machine-readable list of every software component (open-source library, framework, dependency, container image, transitive dependency) inside your application. Think nutrition label for software. It matters because enterprise customers, auditors, and US federal procurement (per Executive Order 14028, May 2021) increasingly require it as supply-chain security evidence. When a vulnerability is disclosed in a popular library (Log4j, Spring4Shell, OpenSSL), an SBOM lets you quickly answer “are we affected?” instead of guessing.
Do I need an SBOM if I’m selling to Indian enterprise customers?
Increasingly yes. Indian enterprise procurement is catching up to global vendor risk standards. Banks, fintechs, and large IT services firms in India have started asking SaaS vendors for SBOMs, though the requirement is less universal than in US federal procurement. If you sell to: US federal customers (mandatory), US enterprises with government exposure (typically required), Indian banks under RBI cybersecurity directives (increasingly required), large global enterprises with mature vendor risk programs (often required), generate one. If your customer base is small Indian businesses, you can defer until a customer specifically asks.
CycloneDX vs SPDX: which format should I generate?
Both. They serve overlapping but distinct purposes. CycloneDX (OWASP project) is more detailed for security use cases, includes vulnerability and license tracking, and is the de facto standard for vendor risk and compliance reporting. SPDX (Linux Foundation, ISO/IEC 5962:2021) is the older standard, more focused on license compliance, and required for some federal procurement. Modern tools (Syft, Trivy) generate both formats from the same scan. Generate both, deliver whichever the customer asks for.
What tools generate SBOMs for SaaS startups?
Free open-source tools cover most needs at startup scale. Syft (by Anchore, generates SBOMs from container images, filesystems, source code) and Trivy (Aqua, generates SBOMs plus vulnerability scanning) are the two most widely used. GitHub Dependency Graph generates a basic SBOM for any GitHub-hosted repo automatically. CycloneDX has language-specific generators (cyclonedx-npm, cyclonedx-python, cyclonedx-go). Paid tools like Snyk SBOM, JFrog Xray, and Sonatype Lifecycle add policy enforcement and integration depth. For Series A SaaS startups, Syft + Trivy free tools cover 80 percent of needs.
How often should I generate a new SBOM?
On every production build, automatically. SBOM generation should run in your CI pipeline so each release artifact has a corresponding SBOM. Manual periodic generation (quarterly, on-demand) misses dependency changes between cycles, which is exactly when supply-chain attacks happen. For startups without mature CI: generate on every release, store the SBOM as a release artifact, and refresh when a customer asks. Tools like Syft and Trivy run in seconds and add negligible CI time.