Modern software is assembled, not written from scratch. A typical application pulls in open source libraries, frameworks, runtimes, and third-party packages, and each of those pulls in dependencies of its own. The result is a deep, layered supply chain that almost no team can describe from memory. A software bill of materials, or SBOM, is the document that makes that supply chain visible. This guide explains what an SBOM is, what it should contain, how the two dominant formats compare, and why it has become a core input for vulnerability management.
What Is a Software Bill of Materials?
A software bill of materials is a structured inventory of every component that makes up a piece of software. The name borrows from manufacturing, where a bill of materials lists every part that goes into a finished product. An SBOM applies the same idea to software. It records the libraries, packages, modules, and other building blocks that ship inside an application, along with the relationships between them.
The U.S. National Telecommunications and Information Administration (NTIA) describes an SBOM as “a formal record containing the details and supply chain relationships of various components used in building software.” That definition has two important parts. The first is the list of components themselves. The second is the relationships between them, which is what tells you how the pieces fit together rather than just which pieces exist.
An SBOM is generated, not handwritten. Tools inspect a codebase, a build artifact, or a container image and emit a machine-readable file. That file can then be read by other tools, shared with customers, attached to a release, or fed into a security platform. The point is that the inventory is precise, reproducible, and consumable by software rather than living in a spreadsheet that drifts out of date.
It helps to be clear about what an SBOM is not. It is not a vulnerability report. It does not tell you which components are risky or which CVEs apply. It only tells you what is present. The security value comes when you cross-reference that inventory against vulnerability data, which is a separate step covered later in this guide.
Why SBOMs Matter for Security
For years, the components inside an application were effectively invisible once the software shipped. If a serious flaw was disclosed in a widely used library, every team had to scramble to answer a single question: are we affected? Without an inventory, answering that question meant manually searching codebases, build files, and dependency manifests across dozens of projects. That manual search is slow, error-prone, and often incomplete.
An SBOM changes the economics of that question. When a new vulnerability is published, a team that maintains SBOMs can search its inventory for the affected component and version, and get an answer in minutes instead of days. The 2021 Log4Shell disclosure made this concrete for many organizations. The flaw lived in a logging library buried deep inside countless applications, and the teams that struggled most were the ones who could not quickly tell where the library was used.
SBOMs also matter because software risk increasingly travels through the supply chain. An attacker does not need to breach your code directly if they can compromise a dependency you trust. Knowing exactly what you depend on, and at what version, is the foundation for managing that exposure. This is why guidance from the Cybersecurity and Infrastructure Security Agency (CISA) treats SBOMs as a baseline practice for software supply chain security, and why regulators and large buyers increasingly ask vendors to provide them.
There is a procurement dimension as well. When you buy or integrate third-party software, an SBOM lets you assess what you are bringing into your environment before you deploy it. Transparency between software producers and software consumers is much of the reason the format exists.
SBOM Formats: CycloneDX vs SPDX
An SBOM is only useful if other tools can read it. That requires a shared, standardized format. Two formats dominate the field, and most tooling supports one or both.
CycloneDX is a specification maintained under the OWASP project. It was designed from the start around application security and supply chain use cases, and it represents components, their relationships, and associated metadata such as licenses and known vulnerabilities. Its emphasis on security context makes it a common choice for AppSec and vulnerability management workflows.
SPDX, the Software Package Data Exchange, is an open standard maintained by the Linux Foundation and published as an international standard under ISO/IEC 5962. SPDX has deep roots in license compliance and was originally focused on communicating licensing and provenance information about software packages. It has since broadened to cover the same component-inventory needs that security teams care about.
In practice the two formats overlap heavily in what they can express, and the right answer is usually whichever format your tools and partners already use. PMAP does not force a choice between them. Its SBOM export capability pulls an SBOM in either CycloneDX or SPDX from a connected software composition analysis vendor, stores the document, and persists its metadata. The format you receive depends on what the upstream SCA tool produces.
What a Minimal SBOM Should Contain
Beyond the choice of format, there is a question of what fields an SBOM must include to be useful. NTIA addressed this with its publication on the minimum elements for an SBOM. The minimum data fields it defines give you enough to identify each component unambiguously and understand how components relate.
At the baseline, each component entry should carry the following minimum elements:
- Supplier name. The entity that creates, defines, or identifies the component.
- Component name. The name assigned to the unit of software.
- Version of the component. The identifier that distinguishes one release from another, which is essential for matching against vulnerability data.
- Other unique identifiers. Identifiers such as package URLs or other references that help locate the component precisely.
- Dependency relationship. How one component relates to another, typically the relationship between an upstream component and the software that includes it.
- Author of the SBOM data. The entity that produced the SBOM entry.
- Timestamp. The date and time the SBOM was generated.
Version accuracy deserves special attention. A vulnerability almost always affects specific versions of a component, so an inventory that records the component name but not its exact version cannot answer the question that matters most. The same applies to the dependency relationship field, which is what makes transitive dependencies visible.
SBOMs and Transitive Dependencies
The hardest part of software supply chain risk is rarely the components you chose on purpose. It is the components those components depend on, which you never selected directly.
A direct dependency is a library your code explicitly imports. A transitive dependency is a library that one of your direct dependencies pulls in, and so on, several layers deep. A single direct dependency can drag in dozens of transitive ones. Most real risk hides in this transitive layer precisely because developers are not consciously aware of it. You do not patch what you do not know you have.
This is where the relationship data in an SBOM earns its place. Because the SBOM records how components relate to one another, it can express the full tree, not just the top layer. The dependency relationship field is what lets a tool walk from your application down through each level of the supply chain.
PMAP complements the stored SBOM with a dependency graph capability. It can fetch the transitive dependency tree for a project from a connected SCA vendor, which gives the layered view of how a deeply nested component arrived in your build. The SBOM tells you what is present. The dependency graph tells you how it got there, which is often the information you need to decide where to apply a fix.
Where SBOMs Come From: SCA Tooling
SBOMs do not appear on their own. Something has to inspect your software and produce the inventory. For most teams, that something is a software composition analysis (SCA) tool.
SCA tools analyze codebases and build artifacts to identify the open source and third-party components they contain. Because identifying components is exactly the input an SBOM needs, SCA tools are a natural source of SBOM documents. They resolve direct and transitive dependencies, attach version information, and emit the inventory in a standard format.
PMAP integrates with SCA vendors including Snyk, Black Duck, and Sonatype. In PMAP’s architecture these connectors follow a pull-only pattern. Rather than running scans on demand, this connector type pulls project-level results on a schedule, which fits the way SCA platforms continuously analyze repositories. When PMAP exports an SBOM, it is pulling that document from one of these connected SCA platforms rather than generating it independently.
If you want the operational walkthrough of wiring Snyk or Black Duck into PMAP and bringing their results in, that procedure is covered separately in the SCA and SBOM integration guide. This guide stays focused on what an SBOM is rather than how to configure a specific connector.
SBOM in a Vulnerability Management Workflow
An inventory becomes a security asset when it feeds decisions. In a vulnerability management workflow, the SBOM provides the component truth that the rest of the process reasons about.
The flow looks like this. An SCA tool analyzes a project and identifies its components. PMAP exports the resulting SBOM in CycloneDX or SPDX, stores the document, and persists its metadata so it can be listed and retrieved later. Alongside the SBOM, PMAP can fetch the project’s transitive dependency graph. Findings that come from the SCA tool are imported through the same integration layer that handles every other scanner, which means SCA results land in the same place as findings from network, web, and code scanners.
The value of having component context next to findings is that it changes what a finding means. A finding tied to a component you can see in the SBOM, at a version you can confirm, with a dependency path you can trace, is far more actionable than a raw vulnerability ID with no context about where the affected code actually lives. When a new disclosure lands, the stored inventory lets you scope impact across projects quickly rather than rediscovering your dependencies under pressure.
This is also why an SBOM is best understood as part of a connected integration layer rather than a standalone artifact. PMAP treats SCA, SBOM export, and dependency graphs as part of a broader security integration layer that unifies scanners, ticketing, and pipelines under one model. The SBOM is one input into that layer, not a side document that lives apart from the workflow.
SBOM vs a Vulnerability Scan: Different Jobs
A common point of confusion is the difference between an SBOM and a vulnerability scan. They are related, they often come from the same tooling, and they are frequently discussed together. They are not the same thing, and treating them as interchangeable leads to gaps.
An SBOM is an inventory. Its job is to answer the question “what is in this software?” It lists components and their relationships. It makes no claim about whether any of those components is vulnerable. An SBOM produced today and an SBOM produced tomorrow describe the same software identically if the build did not change, regardless of what vulnerabilities were disclosed in between.
A vulnerability scan is an assessment. Its job is to answer the question “what is wrong with this software right now?” It produces findings, each tied to a specific issue with a severity, and that result set changes over time as new vulnerabilities are disclosed against components that were already present.
The two are complementary. The SBOM is the stable list of ingredients. The scan is the time-sensitive judgment about which of those ingredients are now dangerous. You cross-reference one against the other to get the answer that matters: which components in my inventory have known vulnerabilities today, and where are they used. An SBOM without scanning is an inventory with no risk verdict. Scanning without an inventory leaves you guessing at scope when the next disclosure arrives. Mature programs keep both, and they keep them connected.
If you are weighing SCA against other testing approaches such as SAST and DAST, that comparison is its own topic and is covered in the SAST vs DAST vs SCA explainer. The short version is that SCA, the family of tooling that produces SBOMs, focuses specifically on the open source and third-party components an SBOM enumerates.
Bringing It Together
An SBOM is the inventory that makes software supply chain risk manageable. It records every component in a piece of software and the relationships between them, in a standardized format such as CycloneDX or SPDX, with enough detail to identify each component and trace its dependencies. It matters because it turns the urgent question “are we affected?” into a fast lookup instead of a frantic search, and because supply chain risk is now a primary attack path.
In a vulnerability management context, the SBOM is most powerful when it is not isolated. PMAP exports SBOMs from connected SCA tools, stores them, fetches the transitive dependency graph alongside them, and feeds the resulting component context into the same workflow that handles findings from every other scanner. The inventory and the findings live together, which is what makes both more useful.
See how PMAP ingests SBOMs and dependency graphs from SCA tools in the ITSM and CI/CD integration platform datasheet.
Frequently Asked Questions
What is an SBOM in simple terms?
An SBOM, or software bill of materials, is a structured list of every component inside a piece of software, along with the relationships between those components. It works like an ingredients label for software. It tells you what your application is made of so you can answer questions about it later, such as whether it contains a component that just had a vulnerability disclosed.
What is the difference between CycloneDX and SPDX?
Both are standardized SBOM formats, and both can express a component inventory with relationships and metadata. CycloneDX is maintained under OWASP and was designed around application security and supply chain use cases. SPDX is maintained by the Linux Foundation, is published as ISO/IEC 5962, and grew out of license compliance before broadening to cover security needs. In practice they overlap heavily, and the right choice is usually whichever your tools and partners already support. PMAP can export an SBOM in either format.
Does an SBOM include vulnerability information?
By itself, an SBOM is an inventory and does not tell you which components are vulnerable. The security value comes from cross-referencing the SBOM against vulnerability data, which is a separate step. Some workflows attach known-vulnerability data to SBOM entries, but the core job of an SBOM is to describe what components are present, not to judge their risk.
Why are transitive dependencies important in an SBOM?
Transitive dependencies are the components that your direct dependencies pull in, often several layers deep, which you never selected on purpose. Most supply chain risk hides in this layer because teams are not aware it is there. A complete SBOM records the dependency relationships, which lets tools walk the full tree. PMAP can also fetch the transitive dependency graph from a connected SCA tool to show how a deeply nested component reached your build.
Where does an SBOM come from?
SBOMs are produced by tooling that inspects your software, most commonly software composition analysis (SCA) tools. These tools identify the open source and third-party components in a codebase or build artifact and emit the inventory in a standard format. PMAP pulls SBOMs from connected SCA vendors such as Snyk, Black Duck, and Sonatype rather than generating them on its own.
Is an SBOM the same as a vulnerability scan?
No. An SBOM is an inventory that answers “what is in this software?” A vulnerability scan is an assessment that answers “what is wrong with it right now?” The SBOM is stable as long as the build does not change, while scan results shift as new vulnerabilities are disclosed. The two are complementary, and you cross-reference one against the other to find which inventoried components have known vulnerabilities today.
How does an SBOM fit into a vulnerability management platform?
In PMAP, an SBOM is exported from a connected SCA tool, stored, and kept alongside the project’s transitive dependency graph. Findings from the SCA tool flow through the same integration layer as findings from every other scanner, so component context sits next to vulnerability findings. That combination makes findings more actionable and lets teams scope the impact of a new disclosure across projects quickly.
