PCI DSS Meets SBOM Requirements

The SBOM-Shaped Hole in PCI DSS

Read PCI DSS v4.0.1 end to end and you won't find the acronym SBOM. The word "bill of materials" doesn't appear either. What does appear, across at least four requirements, is the expectation that entities maintain a "current inventory of all bespoke and custom software" and of "all third-party software components (including libraries)" — language that describes an SBOM without naming one.

This gap between what PCI says and what PCI means has created genuine confusion. I've seen merchants hand QSAs a spreadsheet of Maven dependencies and call it an inventory. I've seen service providers point at GitHub's dependency graph and ask if that counts. Sometimes it does. Sometimes the QSA pushes back. This post is what I wish someone had handed me the first time I answered PCI questions about components.

What v4.0.1 Actually Requires

The relevant requirements cluster around Requirement 6 (Develop and Maintain Secure Systems and Software) and Requirement 12 (Support Information Security with Organizational Policies and Programs).

Requirement 6.3.2 — added as a new requirement in v4.0 and now active after the extended deadline — says the entity must maintain an inventory of bespoke, custom, and third-party software components to facilitate vulnerability and patch management. The applicability notes are explicit: "An inventory of custom, bespoke, and third-party software components incorporated into bespoke and custom software supports the entity in identifying the applicability of newly discovered vulnerabilities."

That is an SBOM, in every meaningful sense. The inventory has to be granular enough to determine whether, say, CVE-2023-44487 (HTTP/2 Rapid Reset) applies — which means knowing every package that links against an affected HTTP/2 library, not just which applications ship an HTTP server.

Requirement 6.3.1 requires the entity to identify security vulnerabilities, assign risk rankings, and manage them — all of which presumes knowledge of what components are actually present. Requirement 6.3.3 requires critical and high-risk patches to be installed within one month. Without an accurate SBOM, the one-month SLA is unmeasurable.

Requirement 11.3.1.1 (new in v4.0) requires internal vulnerability scans to address all applicable vulnerabilities. QSAs increasingly interpret "applicable" to mean "actually deployed in the CDE" — which again requires component-level inventory.

Requirement 12.3.4 requires hardware and software technologies to be reviewed at least every twelve months to confirm they continue to be supported. For open-source components — which have no EOL notice in your inbox — this review is impossible without an SBOM feeding a license and maintenance-status lookup.

What Counts as an Adequate Inventory

PCI SSC published FAQ 1478 clarifying that the inventory "should be in a format that allows for manual review or automated checks." In practice, QSAs look for three things.

First, completeness. The inventory must cover everything in the CDE — applications, runtime libraries, base container images, and dependencies of dependencies. A package.json isn't enough; you need the resolved dependency graph. A direct-dependency manifest misses transitive components, and transitive components ship more than half of the CVEs you'll ever face.

Second, currency. The inventory has to reflect what is actually deployed right now, not what was planned six months ago. "Current" is a word that appears throughout Requirement 6.3.2. That points strongly toward build-time SBOM generation integrated with CI/CD, not a spreadsheet updated ad hoc.

Third, queryability. If a critical CVE lands, the entity has to identify every affected asset within the month-long patch window. A PDF of an SBOM is technically compliant but operationally useless. QSAs are starting to ask how the entity would respond to a given published CVE — the answer needs to be faster than "we'll scan everything."

Format Choices Under PCI

The standard doesn't mandate SPDX or CycloneDX. Either works. For PCI purposes, the format considerations are practical:

• Coverage of the CDE boundary — the SBOM has to capture what's in the cardholder data environment. Containers that don't touch cardholder data are out of scope, but the boundary has to be defensible.
• Inclusion of transitive dependencies — CycloneDX 1.5 makes this explicit through the components array and dependencies graph. SPDX 2.3 supports it through DEPENDS_ON relationships.
• Linkage to vulnerability data — VEX documents (CycloneDX VEX or CSAF VEX) are increasingly important. PCI Requirement 6.3.1 requires risk-ranking; a VEX statement that a CVE is not exploitable in the deployed configuration is a defensible piece of evidence when a QSA asks why a CVSS 9.8 finding wasn't patched within a month.

Mapping SBOM Practice to PCI Requirements

Here is the mapping I build into PCI audit work papers:

• SBOM generation in CI/CD ↔ 6.3.2 (maintain inventory) and 6.4.1 (separate production and pre-production environments — SBOMs should be generated from the production build artifact).
• Transitive dependency resolution ↔ 6.3.1 (identify vulnerabilities) and 6.3.3 (install critical patches within one month).
• VEX statements for unexploitable findings ↔ 6.3.1 (risk ranking) — a signed VEX showing non-exploitability supports a lower risk rank.
• Container image SBOMs for base layers ↔ 6.4.3 (unauthorized code) — knowing what's in the base image is necessary to detect unauthorized additions.
• License and support-status review ↔ 12.3.4 (annual technology review).
• SBOM-driven vulnerability scanning ↔ 11.3.1 (internal scans) and 11.3.1.1 (address applicable vulnerabilities).
• Third-party software attestation ↔ 6.3.2 (third-party components incorporated into bespoke and custom software). For COTS software in the CDE, request the vendor's SBOM as part of due diligence.

Common Pitfalls

The three I see repeatedly:

Treating the SBOM as a snapshot. A single SBOM at the last release is not "current" when the release was six months ago. Build-time generation matters.

Excluding base images. The base OS layer often carries more CVEs than the application layer. If your CDE runs containers, the full layer stack needs to be in the SBOM.

Treating development and production dependencies as one list. A dev dependency with a vulnerability doesn't threaten the CDE. Separate them; otherwise you'll spend the audit cycle explaining why a Jest finding hasn't been patched.

How Safeguard Helps

Safeguard generates CycloneDX 1.5 and SPDX 2.3 SBOMs during CI/CD and keeps them continuously updated with runtime-reachable component data — satisfying PCI DSS v4.0.1 6.3.2's "current inventory" requirement without manual spreadsheets. Vulnerability findings are ranked automatically per 6.3.1, with VEX documents capturing non-exploitability for defensible risk decisions. Policy gates enforce the 6.3.3 one-month critical-patch SLA in the pipeline, and the annual technology review under 12.3.4 is supported by license and support-status metadata attached to every component. When the QSA asks how you would respond to tomorrow's critical CVE, the answer is a query rather than a project.