What Is an SBOM (Software Bill of Materials)? What’s Inside and How Security Teams Use Them

Table of contents - Key Takeaways - What Is a Software Bill of Materials (SBOM)? - BOM vs. SBOM: what’s the difference? - What’s Inside an SBOM? (Key Components) - SBOM Formats and Standards: SPDX vs. CycloneDX - Why SBOMs Matter for Software Supply Chain Security - SBOM Use Cases: How Security Teams Actually Use Them - SBOMs and Compliance: Where They’re Required - How to Generate and Manage an SBOM - SBOM Best Practices (and Common Pitfalls) - How Orca Delivers SBOM Visibility Across the SDLC - Frequently Asked Questions about SBOM Key Takeaways - A software bill of materials (SBOM) is a machine-readable inventory of every component, library, and dependency in a piece of software, including each component’s version, supplier, license, and relationships. Think of it as a nutrition label for software. - An SBOM is not the same as a raw dependency scan. A scanner tells you what to fix today; the SBOM is the durable inventory that lets you answer “are we affected?” the next time a Log4Shell-style vulnerability drops. - Two formats dominate: SPDX (a Linux Foundation and ISO standard focused on license compliance) and CycloneDX (an OWASP standard built for security, with native VEX support). - SBOMs are moving from best practice to requirement. US Executive Order 14028, the EU Cyber Resilience Act, and FDA rules for medical devices already ask for them, and frameworks like NIST SSDF and PCI DSS lean on the same inventory. - An SBOM only earns its keep when it is generated on every build, correlated to live vulnerabilities, and shared. Orca produces SBOMs agentlessly across the SDLC and ties every package to the exploitable risk around it. The World Economic Forum’s Global Cybersecurity Outlook 2026 found that 65% of large companies identify third-party and supply chain vulnerabilities as their greatest barrier to cyber resilience. You cannot defend software when you cannot see what it is built from, and modern applications are built almost entirely from components someone else wrote. A software bill of materials (SBOM) answers that question with a structured, machine-readable inventory of every component in an application, including its libraries, versions, suppliers, dependencies, and licenses. This guide covers what an SBOM contains, how it differs from a BOM and from software composition analysis, the two formats you will actually encounter, and how security teams put an SBOM to work across vulnerability response, compliance, and procurement. What Is a Software Bill of Materials (SBOM)? A software bill of materials (SBOM) is a nested inventory that lists the components a piece of software is made of. SBOM stands for software bill of materials, and the term is borrowed from manufacturing, where a bill of materials lists every part in a finished product. The software version lists code components instead of physical parts. The easiest way to picture it is a nutrition label. A label tells you the ingredients in a packaged food without making you trust the brand blindly. An SBOM does the same for an application: it names each library, its version, and its supplier, so a security team can inspect what shipped instead of assuming the vendor got it right. That matters because most modern applications are not written entirely in-house. They rely heavily on open-source components and third-party dependencies. When you ship software, you ship other people’s code, and the SBOM is the record of exactly whose. BOM vs. SBOM: what’s the difference? A bill of materials (BOM) lists the physical parts in a manufactured product, such as the screws, boards, and wiring in a laptop. A software bill of materials (SBOM) lists the digital components in software: packages, libraries, and modules, down through their transitive dependencies. The concept is the same; the parts are code. The hard part of an SBOM is depth. A single dependency you add on purpose can pull in dozens of others you never chose. A complete SBOM captures those transitive dependencies too, because a vulnerability four layers deep is still running in your application. SBOM vs. SCA (software composition analysis): related but not the same Software composition analysis (SCA) is the process of scanning an application’s open-source components for known vulnerabilities and license risk. An SBOM is the inventory that process produces and maintains. SCA is the activity; the SBOM is the artifact. The distinction is practical. An SCA scan gives you a point-in-time list of issues to fix now. The SBOM persists after the scan, so when a new CVE is published months later, you query the inventory you already have instead of re-scanning every application from scratch. Software composition analysis complements source-code analysis, and understanding SAST vs. SCA helps explain where each approach fits. What’s Inside an SBOM? (Key Components) At minimum, an SBOM records each component’s name, version, supplier, a unique identifier, its license, its relationship to other components, and a cryptographic hash. Together these fields let a machine match a component to a known vulnerability and confirm it has not been tampered with. The unique identifier is what makes automation possible. Two common schemes appear in almost every SBOM: the Package URL (PURL), which encodes ecosystem, name, and version in one string, and the Common Platform Enumeration (CPE), which the National Vulnerability Database uses to map products to CVEs. The NTIA “minimum elements” of an SBOM In July 2021, the US National Telecommunications and Information Administration (NTIA) published the foundational guidance defining the minimum elements of a usable SBOM. It defines three categories: data fields, automation support, and the practices for producing and sharing SBOMs. The seven required data fields are: - Supplier name: the entity that created the component. - Component name: the label for the unit of software. - Component version: so you can distinguish one release from another. - Unique identifiers: such as a PURL or CPE. - Dependency relationship: showing how components relate to one another. - SBOM author: the entity that assembled the SBOM. - Timestamp: when the SBOM was created. Automation support means the file is in a machine-readable format (SPDX, CycloneDX, or SWID). The practices element covers how often you generate or regenerate the SBOM, how comprehensive it is, and how you distribute it. An SBOM that meets the fields but is generated once and never updated fails the practices test. What an SBOM entry looks like: a short example A single entry in an SBOM is a small block of structured data. Here is one component rendered as a table, using a version of Apache Log4j that later became infamous: | Field | Value | |---|---| | Component name | log4j-core | | Version | 2.14.1 | | Supplier | Apache Software Foundation | | Unique identifier (PURL) | pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1 | | License | Apache-2.0 | | Hash (SHA-256) | a1b2c3… (truncated for display) | | Relationship | Dependency of payment-service 3.2.0 | Multiply that block by a few hundred, keep the dependency relationships intact, and you have an SBOM. The value is not the single row. It is being able to search every row across your whole estate in seconds. SBOM Formats and Standards: SPDX vs. CycloneDX Two machine-readable formats dominate the SBOM landscape: SPDX and CycloneDX. Both capture the NTIA minimum elements, both are open standards, and most SBOM tooling can read and write either, so the choice rarely locks you in. A third format, SWID, appears mainly in software asset management. | Format | Steward | Standard | Primary Focus | Common Use | |---|---|---|---|---| | SPDX | Linux Foundation | ISO/IEC 5962:2021 | License compliance and provenance | Broad distribution, license audits, open-source governance | | CycloneDX | OWASP | ECMA-424 | Security, risk, and VEX | Vulnerability management, AppSec pipelines | | SWID | ISO/IEC | ISO/IEC 19770-2:2015 | Software identification | Installed-software tracking, asset management | SPDX (Linux Foundation / ISO standard) SPDX (originally Software Package Data Exchange) is a Linux Foundation project that became an international standard, ISO/IEC 5962:2021. Its heritage is license compliance, so it carries rich metadata about copyrights, license expressions, and provenance. That heritage makes SPDX a common default for organizations whose first SBOM driver is legal and open-source governance. It supports formats from tag-value text to JSON, and the SPDX 3.0 release broadened it toward security and AI use cases. CycloneDX (OWASP) CycloneDX is an OWASP project designed from the start for security use, and it was standardized as ECMA-424 in 2024. It handles the same component inventory as SPDX and adds security-native constructs, most notably Vulnerability Exploitability eXchange (VEX) data that records whether a listed vulnerability is actually exploitable. CycloneDX also extends beyond classic application SBOMs to related bills of materials, including SaaSBOM for services and a machine-learning BOM for AI models and datasets. Teams that lead with vulnerability management tend to reach for it first. SWID tags SWID (Software Identification) tags are defined by ISO/IEC 19770-2 and are used mainly to identify installed software for asset management. NIST references SWID tags when mapping products to vulnerabilities, so they show up in compliance contexts more than in day-to-day AppSec pipelines. Why SBOMs Matter for Software Supply Chain Security An SBOM turns a frantic manual hunt into a database query. When a critical vulnerability lands in a widely used library, the first question every security team asks is “are we affected, and where?” Without an inventory, answering it means grepping through repositories and interrogating vendors for weeks. Log4Shell is the canonical example. In December 2021, a single CVE in Apache Log4j (CVE-2021-44228, scored 10.0) exposed a library buried inside thousands of applications and appliances. Teams with a current SBOM searched their inventory for the affected log4j-core versions and had an answer in minutes. Teams without one spent the holidays reverse-engineering their own software. Beyond incident response, an SBOM delivers concrete gains a raw scan does not: - Transparency into third-party and open-source code you did not write. - Faster vulnerability response, because lookups replace rediscovery. - License and legal risk control, by surfacing copyleft or conflicting licenses before they ship. - Compliance evidence you can hand to auditors and customers. - Vendor trust, because you can demand the same inventory from your suppliers. SBOMs become even more valuable when defending against software supply chain attacks, because they let teams identify affected components quickly. SBOM Use Cases: How Security Teams Actually Use Them Security teams treat the SBOM as an operational data source, not a document that sits in a compliance folder. Four uses cover most of the value. Vulnerability management + VEX The core workflow maps each component in the SBOM to known vulnerabilities in sources like the National Vulnerability Database and OSV, then ranks what to fix. The problem is noise: a library can contain a vulnerable function your code never calls, producing a false alarm. Vulnerability Exploitability eXchange (VEX) solves that. VEX is a companion document that states, per vulnerability, whether a product is actually affected. Pairing an SBOM with VEX cuts the false-positive flood so teams patch what is reachable instead of chasing every theoretical match. This pairs naturally with attack path analysis, which asks whether a vulnerable component is exposed at all. License and compliance management Every component carries a license, and some licenses impose obligations that clash with how you ship. An SBOM lets legal and engineering flag a copyleft license like GPL inside a proprietary product before release, not during due diligence. This is also where SBOMs earn their place in mergers and acquisitions. An acquirer reads the target’s SBOM to price the open-source and license risk it is buying, instead of taking the seller’s word for a clean codebase. Incident / zero-day response When the next zero-day drops, the SBOM is the fastest path to scope. A team queries every SBOM across its portfolio for the affected package and version range and gets an exact list of impacted services, including the transitive matches a surface-level scan would miss. That speed is the difference between a same-day containment plan and a week of uncertainty. The inventory you built for compliance quietly becomes your best incident-response asset. Procurement, M&A, and third-party risk Buyers increasingly require an SBOM before they purchase or renew software. Requesting one shifts third-party risk from a questionnaire full of self-attestations to an inspectable inventory of what the vendor actually ships. The same logic runs in reverse. If your customers are enterprises or government agencies, expect the SBOM request to arrive in the security review, and expect to produce one on demand. SBOMs and Compliance: Where They’re Required Increasingly, yes, an SBOM is legally required, though it depends on your market and buyer. Several mandates now name the SBOM directly, and more frameworks assume the inventory it provides. - US Executive Order 14028 (2021) directed federal agencies to require SBOMs from software suppliers, with the NTIA minimum elements as the baseline. - The EU Cyber Resilience Act requires manufacturers of products with digital elements to produce and maintain SBOMs, with its main obligations applying from 11 December 2027 and reporting obligations from 11 September 2026. - FDA rules require an SBOM in premarket submissions for cyber devices, under section 524B of the FD&C Act. - FedRAMP and US federal procurement guidance increasingly expect SBOMs from cloud service providers. Other frameworks lean on the same inventory without always naming it. The NIST Secure Software Development Framework (SP 800-218), DORA in EU financial services, and PCI DSS requirement 6.3.2 all expect you to track your software components, which is exactly what an SBOM records. Treat SBOM generation as the foundation that satisfies several of these at once. How to Generate and Manage an SBOM You generate an SBOM by running a tool that inspects your software and emits SPDX or CycloneDX, then you regenerate it on every build so it never goes stale. The harder question is where in the lifecycle you capture it, because that decides how accurate it is. Generation methods: source, build-time, and binary/runtime There are three main points to generate an SBOM, and they trade completeness against convenience: - Source analysis reads manifests and lockfiles (package.json, pom.xml, go.sum) in the repository. It is fast and early but can miss what the build actually pulls in. - Build-time generation runs inside CI as the artifact is assembled. It is the most accurate, because it records the components that truly ship, including build-injected ones. - Binary or runtime analysis inspects a compiled artifact or container image after the fact. It is the fallback when you do not control the build, such as third-party or legacy software. For workloads shipped as container images, binary analysis of the image is often the practical choice, since it captures the full runtime layer. SBOM tools and generators A healthy open-source ecosystem produces SBOMs. Syft, Trivy, and the CycloneDX and SPDX command-line generators all emit standard formats and integrate into CI pipelines. Standalone generators are only the first step. They create the file, but they do not correlate it to your live environment or keep it current across hundreds of services. Platform-based generation closes that gap by continuously maintaining and enriching SBOM data across the software estate. Managing SBOMs at scale One SBOM is a file; ten thousand SBOMs are a data problem. Managing them means storing every version, regenerating on each build, and being able to query the whole set at once when a vulnerability lands. The other half is distribution. SBOMs are only useful when they reach the people who need them, whether that is an internal incident-response team or a customer’s security reviewer. Automated export and scheduled sharing beat emailing a stale file on request. This is a natural extension of application security posture management, which centralizes findings across the software estate. SBOM Best Practices (and Common Pitfalls) The practices that separate a useful SBOM program from a checkbox one are consistent, and so are the mistakes. Start with the habits: - Automate generation in CI/CD so every build produces an SBOM without human effort. - Generate at build time for accuracy, and regenerate on every release so the inventory tracks reality. - Standardize on SPDX or CycloneDX rather than a home-grown format. - Capture transitive dependencies, not just the ones you declared. - Sign and verify SBOMs, using tooling like Sigstore, so consumers can trust provenance. - Correlate the SBOM to live vulnerabilities and exposure, not just a static component list. The pitfalls mirror those habits. A stale SBOM describes software you no longer run. An incomplete one that skips transitive dependencies hides the exact components attackers target. And an SBOM stored but never queried against real risk is documentation, not security. Continuous correlation is one of the cloud application security best practices that keeps an SBOM from becoming shelfware. How Orca Delivers SBOM Visibility Across the SDLC Orca generates SBOMs across the software development lifecycle using patented SideScanning™, giving security teams a continuously updated inventory of packages and dependencies across code repositories and cloud workloads. Orca centralizes SBOM visibility across the software estate without relying on separate scanners for every repository. It exports SBOMs in SPDX, CycloneDX, CSV, and JSON formats and correlates every component with vulnerabilities, identities, misconfigurations, and cloud context to prioritize the risks that are actually exploitable in your environment. By combining continuous SBOM generation with attack-path analysis and cloud context, Orca helps security teams keep software inventories current, respond faster to new vulnerabilities, and simplify compliance reporting. Get a demo to see how Orca helps secure your software supply chain. Frequently Asked Questions about SBOM In some cases, yes. US Executive Order 14028 requires SBOMs from software suppliers to federal agencies, the EU Cyber Resilience Act requires them for products with digital elements, and FDA rules require them for certain cyber devices. Even where they are not explicitly mandated, frameworks such as NIST SSDF, PCI DSS, and DORA expect organizations to maintain an inventory of their software components. An SBOM should be regenerated every time software is built or released. A static inventory quickly becomes outdated as dependencies change, new components are added, and vulnerabilities are disclosed. Automating SBOM generation in CI/CD pipelines helps ensure the inventory accurately reflects the software that is actually deployed. No. An SBOM does not prevent attacks on its own, but it gives security teams the visibility needed to respond quickly when a vulnerable or compromised component is discovered. By identifying where affected components are used, teams can assess exposure, prioritize remediation, and reduce the impact of software supply chain attacks. Increasingly, yes. Many enterprise customers, government agencies, and regulated industries now request SBOMs as part of procurement and security reviews. Providing an up-to-date SBOM improves transparency, supports compliance, and helps customers evaluate software supply chain risk. An SBOM is the inventory of the software components that make up an application. Software composition analysis (SCA) is the process of analyzing those components for vulnerabilities, license issues, and other risks. SCA uses the SBOM as one of its primary data sources, while the SBOM remains a reusable inventory that can be queried whenever new vulnerabilities are disclosed. Table of contents - Key Takeaways - What Is a Software Bill of Materials (SBOM)? - BOM vs. SBOM: what's the difference? - What's Inside an SBOM? (Key Components) - SBOM Formats and Standards: SPDX vs. CycloneDX - Why SBOMs Matter for Software Supply Chain Security - SBOM Use Cases: How Security Teams Actually Use Them - SBOMs and Compliance: Where They're Required - How to Generate and Manage an SBOM - SBOM Best Practices (and Common Pitfalls) - How Orca Delivers SBOM Visibility Across the SDLC - Frequently Asked Questions about SBOM