SBOM (Software Bill of Materials)

What is an SBOM?

An SBOM, or Software Bill of Materials, is a structured, machine-readable list of every component in your software. It catalogs your direct dependencies (packages you explicitly import), transitive dependencies (packages your dependencies depend on), their versions, their suppliers, and their relationships to each other.

Think of it like a nutrition label for software. Just as a food label tells you exactly what's in the product you're consuming, an SBOM tells you exactly what's in the software you're shipping or running.

Two standard formats for SBOMs include:

1. CycloneDX. Maintained by the OWASP Foundation and standardized as ECMA-424. CycloneDX is security-focused, with native support for vulnerability data and VEX (Vulnerability Exploitability eXchange) information that tells consumers whether a known vulnerability is actually exploitable in a given context.
2. SPDX. Maintained by the Linux Foundation and standardized as ISO/IEC 5962:2021. SPDX has deeper roots in license compliance, making it particularly useful for organizations that need to track open-source license obligations alongside security data.

Both formats satisfy regulatory requirements. Which one you use typically depends on your primary use case (security-focused vs. license-focused) and what your tooling supports.

Why do SBOMs matter for startups?

1. The government is mandating them. Executive Order 14028 requires software vendors selling to federal agencies to provide SBOMs. The NTIA published minimum elements that every SBOM must include: supplier name, component name, component version, and unique identifiers. CISA has continued expanding guidance, and in 2025, CISA, the NSA, and 19 international partner agencies published joint guidance endorsing SBOM requirements globally. The EU Cyber Resilience Act will require manufacturers to produce SBOMs by December 2027. The regulatory direction is clear: SBOMs are becoming table stakes.
2. Enterprise buyers are asking for them. SBOMs are showing up in security questionnaires alongside requests for SOC 2 reports and pen test results. Enterprise procurement teams want to know what's in the software they're buying, especially after high-profile supply chain incidents. Having an SBOM ready to share on demand signals maturity and transparency.
3. They make vulnerability response dramatically faster. When a new critical vulnerability is disclosed, the first question is often "Are we affected?" Without an SBOM, answering that question means manually auditing every application, scanning every server, and contacting every vendor. Organizations with SBOMs can answer that question in minutes by querying their component inventory. Organizations without SBOMs often need weeks to get the answers they seek.
4. You don't know what's in your software. A typical application today has hundreds of direct dependencies and thousands of transitive dependencies. Your team likely selected the top-level packages, but nobody reviewed the dependency tree three levels deep. An SBOM makes this invisible supply chain visible, which is the first step toward managing the risk it carries.

What goes into an SBOM?

The NTIA minimum elements specify three categories:

1. Data fields. The baseline information for each component: supplier name, component name, version string, unique identifiers (like Package URLs or CPEs), dependency relationships, and the author of the SBOM data.
2. Automation support. SBOMs must be machine-readable (not PDFs or spreadsheets) in a standard format (CycloneDX or SPDX) so they can be programmatically consumed, queried, and integrated with vulnerability databases.
3. Practices and processes. SBOMs should be generated as part of the build process (not manually assembled), updated with each release, and made available to downstream consumers on request.

SBOMs and vulnerability management

An SBOM on its own is just an inventory. Its real value comes from what you do with it:

• Cross-reference against vulnerability databases. Match your SBOM components against the NVD, OSV, or other vulnerability databases to identify which components have known CVEs. This is essentially what SCA tools do, and an SBOM is the foundation they work from.
• Respond to zero-day disclosures. When a new vulnerability is announced, query your SBOMs to instantly determine which applications, services, and environments are affected. No manual scanning required.
• Assess transitive risk. Your direct dependencies are the ones you chose. Transitive dependencies are the ones that came along for the ride. An SBOM exposes the full dependency tree, so you can identify risk in components you never explicitly selected.
• Share with customers and auditors. An SBOM demonstrates transparency and enables your customers to assess the risk of your software within their own environment.

Auto-generate SBOMs with Fencer

Fencer automatically inventories every open-source package across your connected repositories and generates SBOMs on demand in CycloneDX or SPDX formats. Beyond generation, Fencer continuously monitors your dependencies for new vulnerabilities and license risks, so your SBOM isn't just a static document. Instead, it's a live inventory that alerts you when something in your supply chain changes.