Software Bill of Materials (SBOM) — do you need one for your AI-built app?
An SBOM is a machine-readable inventory of every software component in your application — direct dependencies, transitive dependencies, versions, licenses, suppliers. Procurement teams at large enterprises and the US federal government now require them; the EU's Cyber Resilience Act will require them for products sold in the EU starting late 2027. The good news: generating one for a JS or Python app takes minutes with the right tool.
What an SBOM contains
The NTIA's minimum-elements specification (October 2021) defines the baseline. An SBOM must include:
- Supplier name — who produced each component
- Component name — the name of each component
- Version — the specific version of each component
- Other unique identifiers — at least one of: PURL, CPE, SWID
- Dependency relationships — which components depend on which
- Author of SBOM data — who created the SBOM
- Timestamp — when the SBOM was generated
Most SBOMs include more — license info, vulnerability data, integrity hashes. The most-adopted formats are SPDX (originally Linux Foundation) and CycloneDX (originally OWASP). Both are JSON or XML; both are interchangeable for most use cases.
Who actually requires one
US federal procurement
Executive Order 14028 (May 2021) directed agencies to require SBOMs from software vendors. NIST SP 800-218 (Secure Software Development Framework, SSDF) operationalized this. As of 2024-2026, federal agencies routinely require SBOMs as part of contract submissions for IT and software services. If you're selling to federal government, you'll be asked for one.
Large enterprise procurement
Fortune 500 procurement teams, especially in finance and healthcare, increasingly require SBOMs from software vendors as part of the third-party-risk-management (TPRM) process. The pattern: a vendor security questionnaire that asks "do you maintain an SBOM and can you share it?" Anyone selling B2B SaaS upmarket has hit this.
EU Cyber Resilience Act (effective late 2027)
The EU CRA, in force since December 2024 with main obligations applying from December 2027, requires manufacturers of "products with digital elements" to maintain an SBOM, monitor it for vulnerabilities, and provide updates. The scope is broad — SaaS is not directly covered, but software products that customers install or download are. The boundary is being clarified in EU guidance.
Industry-specific
FDA requires SBOMs for medical-device software (premarket cybersecurity guidance, 2023). Automotive SPICE references SBOM. Energy-sector NERC CIP regulations are moving toward SBOM requirements. If you're in any regulated vertical, expect SBOM in your future.
Related: Acquisition diligence checklist (SBOMs are increasingly an asked-for item) →Generating an SBOM for a typical AI-built app
For npm/pnpm/yarn apps
Use CycloneDX or Syft. Both are free, both work in seconds:
- CycloneDX: `npx @cyclonedx/cyclonedx-npm --output-format json --output-file sbom.json`. Generates a CycloneDX-format SBOM from package-lock.json or pnpm-lock.yaml.
- Syft (Anchore): `syft packages dir:. -o spdx-json > sbom.json`. Generates either SPDX or CycloneDX. Works on the source directory or on a built Docker image.
- SPDX SBOM Generator: `spdx-sbom-generator -p . -o sbom`. Older but well-supported, generates SPDX format only.
For Python apps
Use `cyclonedx-bom` (`pip install cyclonedx-bom`) or `syft`. Both scan `requirements.txt`, `Pipfile.lock`, or `pyproject.toml`/`poetry.lock`.
For multi-language stacks
Replit-style apps that mix Python + JS, or full-stack apps with Node backend + Python ML, need to generate separately per language tree and either merge or maintain two SBOMs. Syft handles both in a single invocation; CycloneDX requires language-specific tools.
The AI-specific complication
Standard SBOM tools catch your declared dependencies — packages in `package.json`, `pyproject.toml`, etc. They don't catch:
- Code that your AI tool reproduced from training data without going through npm. The standard SBOM tools see this as your own code; the original license obligations still travel with it.
- Vendored libraries — code copied from another repo into your codebase directly instead of installed as a package.
- Build-time-only code that doesn't show up in your runtime dependency graph.
- AI models themselves. If your app ships with an ONNX model, a TensorFlow checkpoint, or downloads weights at runtime, that model has its own license and provenance that aren't captured by code-level SBOM tools.
Best-practice for AI-built apps is to combine SBOM generation with a bundle fingerprint scan (which catches the AI-reproduced code) and a model-provenance log (for any AI weights or models in your deployment).
Related: AGPL in AI-built apps (the same detection problem) →How to use the SBOM once you have it
- Vulnerability scanning. Tools like Grype, Trivy, or Snyk can ingest an SBOM and flag known CVEs. Set up CI to fail builds on high-severity issues.
- License compliance. Pipe the SBOM through `license-checker` or `cyclonedx-license-scanner` to catch unexpected copyleft licenses early.
- Customer disclosure. Some enterprise customers want a copy. Ship a redacted version (omit any sensitive internal naming) on request.
- Audit trail. Generate the SBOM on every release and store with the build artifacts. If a future CVE breaks across multiple versions, you can trace which releases shipped which dependency versions.
When you actually need one
Most early-stage SaaS apps don't yet need an SBOM. The triggers are:
- You're selling to federal government or its prime contractors.
- You're selling to enterprise (especially financial services, healthcare, government adjacent) and being asked for one in a TPRM questionnaire.
- You ship software products (not just SaaS) into the EU and are within scope of the CRA.
- You're in a regulated industry (medical devices, automotive, energy) with industry-specific SBOM mandates.
- You're heading into acquisition diligence (increasingly a standard ask).
If none of those apply yet but you can see them on your horizon, build the SBOM generation into your CI now. The lift is 30 minutes one-time and a few seconds per build; it's much cheaper to start than to retrofit.
Common questions.
What format should my SBOM be in — SPDX or CycloneDX?
Both are widely accepted. CycloneDX is slightly more popular in security tooling (it has richer vulnerability data structures); SPDX is more popular in license-compliance tooling. If you're unsure, pick CycloneDX — it's the default for most modern tools and converts cleanly to SPDX if a customer requires that format.
Does an SBOM expose IP or trade secrets?
Generally no. An SBOM lists what dependencies you use, not your proprietary code. Some teams worry that revealing exact dependency versions enables targeted attacks against known CVEs, but the modern view is that the security benefits of SBOM disclosure (vulnerability tracking, supply-chain transparency) outweigh the obscurity benefits.
Can I just generate an SBOM at acquisition time instead of maintaining one?
You can, but the SBOM is more valuable when it's current and continuously maintained. Acquirers ask whether you have an SBOM process, not just an SBOM artifact. Generating one fresh for diligence works but signals weaker compliance maturity than continuous generation.
What about AI model SBOMs — is there a standard?
Emerging. The OpenSSF AI/ML SBOM working group is developing extensions to SPDX and CycloneDX for AI models. As of 2026 the specifications are draft. For now, maintain a manual log of any AI model weights or checkpoints you ship with, including source, license, version, and training-data provenance (where available).