Skip to main content
Commerce Security Authority
Category: Vulnerability and Software Security

Software Bill of Materials

Also known as: SBOM, software bill of materials, software BOM
Simply put

A Software Bill of Materials (SBOM) is a detailed list of the software components and ingredients that make up an application, similar to a list of ingredients on a food label. It typically includes open source libraries, third-party components, and the dependencies bundled inside the software. Organizations use it to understand what is inside the software they build or run, which supports software supply chain risk management.

Formal definition

An SBOM is a machine-readable, often nested inventory of the software components and dependencies contained within a parent piece of software, including open source and third-party components. According to CISA, it has emerged as a key building block in software security and software supply chain risk management, and the OpenSSF describes it as an artifact enumerating the components and dependencies included in a parent software product. The evidence provided does not specify SBOM data formats, required fields, or any relationship to PCI DSS or other payment security standards, so those details should be confirmed against authoritative specifications and the applicable standard.

Why it matters

Modern applications are assembled largely from open source libraries and third-party components rather than written entirely from scratch, which means the security posture of software depends heavily on ingredients an organization did not author. A Software Bill of Materials gives visibility into those components, and CISA describes it as a key building block in software security and software supply chain risk management. Without a reliable inventory of what is inside the software they build or run, organizations struggle to answer basic questions when a vulnerability is disclosed in a widely used component.

For payment security and merchant risk teams, that visibility supports faster and more accurate response. When a flaw is reported in a commonly used library, an SBOM helps an organization determine whether the affected component is present in its applications and where, which is a prerequisite for prioritizing remediation. The evidence provided does not establish any specific relationship between SBOMs and PCI DSS or other payment security standards, so whether and how an SBOM factors into a particular compliance program should be confirmed against the applicable standard and its current published version.

An SBOM is an inventory, not a control that removes risk on its own. Its value depends on being accurate, kept current as software changes, and actually used to drive vulnerability management and supplier due diligence. A stale or incomplete SBOM can create a false sense of coverage, so it should be treated as one input to software supply chain risk management rather than a guarantee of software integrity.

Who it's relevant to

Security engineers and application security teams
These teams use SBOMs to understand the open source and third-party components inside applications and to locate affected components quickly when a vulnerability is disclosed. The SBOM supports triage and remediation prioritization, though its usefulness depends on the inventory being accurate and kept current as the software changes.
Compliance officers
Compliance staff may consider whether an SBOM supports software supply chain risk management within their programs. The evidence provided does not establish any relationship between SBOMs and PCI DSS or other payment security standards, so any applicability, expectation, or requirement should be confirmed against the applicable standard and its current published version rather than assumed.
Merchant risk and third-party risk teams
Teams assessing software vendors and internally built applications can use an SBOM as one input into supplier due diligence and software supply chain risk management, helping them reason about what components a piece of software contains. It is an inventory rather than an assurance of security, so it should be combined with other risk assessment practices.
Payment processors and acquirers
Organizations that build or operate software supporting payment flows may use SBOMs to maintain visibility into the components in their environments and to respond to newly disclosed component vulnerabilities. How an SBOM interacts with any specific payment security standard is not addressed in the evidence provided and should be verified against the relevant standard.

Inside SBOM

Component inventory
A structured list of the software components included in a product or application, typically covering both first-party code and third-party or open-source dependencies, including transitive dependencies.
Version identifiers
Specific version numbers for each listed component, which help teams determine whether a given release is affected by a disclosed vulnerability. Accuracy depends on the completeness and freshness of the underlying data.
Supplier and provenance information
Details about the origin of each component, such as the supplier, author, or upstream source, intended to support traceability of where code came from.
License information
Data identifying the licensing terms associated with components, which supports license compliance review separate from security review.
Dependency relationships
Information describing how components relate to one another, including which components depend on others, so transitive risk can be understood rather than only top-level packages.
Unique identifiers
Machine-readable references (such as package or component identifiers) that help correlate a component against vulnerability data sources. Correlation quality varies with identifier consistency.
Standard format and metadata
SBOMs are commonly expressed in machine-readable formats to support automation, along with metadata such as who generated the SBOM and when, which affects how current the data is.

Common questions

Answers to the questions practitioners most commonly ask about SBOM.

Does having an SBOM by itself make my software or environment PCI DSS compliant?
No. An SBOM is an inventory of the components, libraries, and dependencies within a software product; it does not by itself demonstrate compliance with any requirement. PCI DSS addresses secure software development, vulnerability management, and change control through its own requirements, and the PCI Software Security Framework governs software security validation separately. An SBOM can support processes such as identifying vulnerable components, but it is an input to those processes rather than evidence of compliance. Confirm how any control is validated against the current published standard rather than treating an SBOM as a compliance artifact in itself.
Is an SBOM the same thing as a vulnerability scan or a patch list?
No. An SBOM describes what components are present in a piece of software, including versions and dependency relationships. It does not, on its own, tell you which of those components are vulnerable, which patches are available, or what your remediation status is. Determining exposure requires correlating the SBOM against vulnerability data sources, and any resulting risk assessment depends on how a component is used, configured, and whether it is reachable. Treat the SBOM as a foundational inventory that feeds vulnerability management, not as a replacement for scanning, patching, or the associated PCI DSS processes.
How does an SBOM support vulnerability management in a payment environment?
An SBOM provides the component and version inventory needed to identify whether newly disclosed vulnerabilities affect software in scope. When a vulnerability is announced, teams can compare it against SBOM contents to locate affected components more quickly than manual review allows. This helps reduce the time to identify potentially affected systems, but it does not by itself confirm exploitability or remediation. The effect on your vulnerability management program depends on how current the SBOM is kept, the quality of the data sources it is correlated against, and how findings are triaged and validated.
When should an SBOM be generated and updated in the software lifecycle?
An SBOM is intended to reflect the components actually present in a given build or release, so it is commonly generated as part of the build or release process and regenerated when components change. A stale SBOM may misrepresent what is deployed, which can lead to both missed vulnerable components and false assumptions about exposure. Aligning SBOM generation with your change control and release processes helps keep the inventory accurate. How frequently you update depends on your development cadence and the criticality of the software to your cardholder data environment.
Should we request SBOMs from our third-party software vendors and payment application providers?
Requesting SBOMs from vendors can improve visibility into components you do not build yourself, which may support third-party risk assessment and vulnerability response. However, availability, format, and completeness of vendor SBOMs vary, and receiving one does not transfer responsibility for how you assess or act on it. Any reliance on a vendor SBOM should be paired with contractual expectations and your own validation processes. Note that PCI DSS obligations for third-party service providers and any software security validation under the PCI Software Security Framework are governed by their respective requirements, which you should confirm against the current published standards.
What formats and details should an SBOM include to be useful for security teams?
To support identification and correlation, an SBOM is generally more useful when it lists components with sufficient detail to match them to vulnerability data, such as component names, versions, and dependency relationships. Machine-readable, standardized formats help automate correlation and integration with existing tooling. The appropriate level of detail depends on how the SBOM will be consumed and by which processes. Because an SBOM feeds downstream analysis rather than producing conclusions on its own, its value is tied to consistency, accuracy, and how it integrates with your vulnerability management and change control workflows.

Common misconceptions

An SBOM is a PCI DSS deliverable with a fixed, mandated requirement number.
An SBOM is a software supply-chain artifact and is not the same as any single PCI standard. Software security expectations for payment software are addressed by the PCI Software Security Framework (and historically PA-DSS), while PCI DSS governs the cardholder data environment. Whether and how SBOM-related practices map to a specific requirement depends on the current published standard, so confirm against the relevant standard rather than assuming a fixed requirement number.
Having an SBOM means the software is secure or free of vulnerabilities.
An SBOM is an inventory, not a control that remediates anything. It can help reduce time to identify potentially affected components when a vulnerability is disclosed, but it does not by itself detect, prioritize, or fix issues. Its usefulness depends on accuracy, completeness, and how it is operationally consumed.
An SBOM is a one-time document generated at release.
Component and vulnerability data change over time, so an SBOM reflects a point in time. Without regeneration when software changes and continuous correlation against updated vulnerability data, an SBOM can become stale and give a false sense of coverage.

Best practices

Generate SBOMs in a machine-readable, standardized format so they can be consumed by automated tooling rather than reviewed only manually.
Capture transitive dependencies, not just top-level packages, so risk hidden deeper in the dependency tree is visible.
Regenerate the SBOM whenever the software changes and record generation metadata (who and when) so consumers know how current the data is.
Correlate SBOM component and version data against updated vulnerability sources on an ongoing basis, and treat matches as candidates for triage rather than confirmed exploitable findings, accounting for false positives and negatives.
Obtain and validate SBOMs from third-party and payment software suppliers as part of supply-chain review, without assuming an SBOM alone satisfies any specific standard's requirements.
Use the SBOM to support, not replace, existing software security and compliance activities, mapping its use to the current applicable PCI standard rather than an assumed requirement number.