Among the changes in PCI DSS 4.0 — a significant update to the Payment Card Industry Data Security Standard — was the introduction of a new SBOM (software bill of materials) requirement. Starting on March 31, 2025, every instance of bespoke and custom software will be required to carry an inventory of software components.
Although PCI DSS is not prescriptive about how the inventory should be structured or what metadata it should include, the most practical and scalable way to fulfill the requirement is by producing SBOMs.
In this blog, we’ll explain why that’s the case, the specific SBOM requirements and timelines in PCI DSS 4.0, and steps organizations can take now to prepare for the March 2025 enforcement date.
Note: PCI DSS v4.0.1 was released in mid-June, 2024, and, as such, PCI DSS v4.0 will be retired on Dec. 31, 2024. However, 4.0.1 is only a “limited revision” to 4.0 and doesn’t include any new (or removed) requirements, nor does it impact the timelines laid out in 4.0. Accordingly, this blog’s analysis of the SBOM requirements introduced in PCI DSS 4.0 is applicable to both 4.0 and 4.0.1.
PCI DSS: Scope and Background
PCI DSS is a security standard designed to ensure all companies that accept, process, store, transmit, or otherwise interact with credit card information maintain a secure environment. The environment in which payment processing takes place is referred to as the CDE, or cardholder data environment. (PCI-DSS frequently uses this term to refer to systems that store, process, or transmit cardholder data, though the standard also applies to systems that are not in the CDE but can adversely impact the CDE.)
Version 4.0 of PCI DSS was officially released in March 2022. The transition period from the previous version (3.2.1) to version 4.0 has been gradual to allow organizations time to adapt — full enforcement of version 4.0 will start on March 31, 2025. Until that date, both versions 3.2.1 and 4.0 are considered valid for compliance assessments. However, after March 31, 2025, all entities will be required to assess compliance based on the requirements of PCI DSS version 4.0, which includes SBOMs.
PCI assessments differ depending on the volume of transactions merchants process. Level 1 merchants — which process over six million transactions each year — must undergo an on-site assessment. Merchants that process a smaller volume of transactions are required to complete self-assessment questionnaires (SAQ) rather than on-site audits. (Additional requirements, such as penetration tests and network scans, also apply to multiple merchant levels.)
Similarly, Level 1 service providers also must go through the full assessment process, while Level 2 service providers should complete the annual (SAQ).
PCI DSS Requirement 6.3.2 (Component Inventory for Vulnerability Management)
PCI DSS Principal Requirement 6 is titled “Develop and Maintain Secure Systems and Software.” Section 6 covers five primary areas:
Requirement 6.3.2 — under the “Security vulnerabilities are identified and addressed” category — is as follows:
An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
This requirement can be broken down into two primary elements. The first (“inventory”) is where the SBOM comes into play. The second (“facilitating vulnerability and patch management”) aims to ensure the SBOM is being used to enable vulnerability management — just having an SBOM sitting in a folder won’t be sufficient.
The ultimate goal (“Customized Approach Objective”) of Requirement 6.3.2 is to ensure “known vulnerabilities in third-party software components cannot be exploited in bespoke and custom software.”
Testing Procedures
PCI DSS assessors are expected to test for compliance (“Defined Approach Testing Procedures”) with Requirement 6.3.2 in the following ways:
6.3.2.a Examine documentation and interview personnel to verify that an inventory of bespoke and custom software and third-party software components incorporated into bespoke and custom software is maintained, and that the inventory is used to identify and address vulnerabilities.
6.3.2.b Examine software documentation, including for bespoke and custom software that integrates third-party software components, and compare it to the inventory to verify that the inventory includes the bespoke and custom software and third-party software components.
PCI DSS SBOM Requirement Analysis
We’ll go into more detail about strategies for complying with 6.3.2 later in this blog, but it’s worth keeping a few things in mind as you digest the specifics.
- SBOM format and data fields
In contrast to SBOM requirements from the FDA and NTIA, PCI DSS does not require the software inventory to include specific data fields or be in a specific format. It also doesn’t touch on how often the SBOM should be updated.
- SBOM depth and completeness
On the other hand, PCI DSS is clear that SBOMs should include all first- and third-party software components. This, of course, means simply inventorying your own code and open source dependencies won’t be sufficient — you’ll also need to get SBOMs from your suppliers (if you have suppliers).
Additionally, while PCI DSS doesn’t touch on how many levels of dependencies SBOMs should include, it does require your SBOM to cover “all payment software components and dependencies, including supported execution platforms or environments, third-party libraries, services, and other required functionalities.” While not explicit in its direction, we interpret “all dependencies” as needing a full dependency graph of all direct and transitive dependencies included in first- and third-party software components.
- Operationalizing your SBOM
Part of testing procedure 6.3.2.a is that “the inventory is used to identify and address vulnerabilities.” In other words, it’s expected that you will use your SBOM as the foundation for actively managing vulnerabilities — simply producing one and storing it in Google Drive, never to be seen again, won’t suffice.
This is another reason why maintaining machine-readable SBOMs (that allow for vulnerability analysis) and using SBOM management tooling are important considerations. In practice, assessors will require you to produce SBOMs for all versions of software and validate that a vulnerability management program is in place to continuously address exploitable vulnerabilities.
Preparing for PCI DSS SBOM Requirements
Although there are still several months before PCI's SBOM requirements take effect, organizations can (and often should) take certain steps now to prepare for compliance.
- Setting internal SBOM policies
As discussed, PCI DSS isn’t prescriptive when it comes to SBOM data fields, format, update frequency, or dependency depth. So, you’ll want to make sure you get alignment between the PCI-covered product lines in your business on your internal SBOM policies.
There’s no one-size-fits-all “best” standard or set of standards, but we do recommend consulting the NTIA’s minimum SBOM elements as a starting point. The NTIA document includes guidance for SBOM data fields, formats, update frequency, and more. In particular, we suggest including a unique identifier such as PURL (preferable) or CPE, as doing so helps enable continuous vulnerability detection.
(We should also note that although the NTIA covers three acceptable SBOM formats — SWID, CycloneDX, and SPDX — we strongly recommend you produce and ingest SBOMs in either CycloneDX or SPDX. SWID isn’t currently very popular and is also more of a software description than SBOM format per se.)
- Determining the scope of your PCI DSS SBOMs
When configuring SBOM tooling, it’s important to be mindful of which applications are both a) directly part of the CDE and b) indirectly impact the CDE. If, say, an application is used in a credit card machine, you will obviously need to maintain an SBOM for that program. But you’ll also need to create SBOMs for applications downstream of CDE if said applications are connected to the CDE — for instance, a SaaS application that supports the credit card machine. This SBOM scoping will likely go hand in hand with the segmentation you’ve done/are doing for other PCI requirements, but it is an important part of creating a complete inventory.
- Getting SBOMs from third-party suppliers
Requesting and obtaining SBOMs from third-party suppliers (that you’d combine with the SBOMs you generate that document your own code and open source dependencies) is a more complex task than some organizations realize.
For one, your supplier may not currently have the ability to produce an accurate SBOM that meets your standards for accuracy and completeness. Even if they do, there’s the challenge of incentivizing your suppliers to produce and transmit the SBOM. Where possible, consider contractual language to make this a requirement.
Of course, there’s also the matter of what, exactly, needs to go into your suppliers’ SBOMs. Should it be in CycloneDX or SPDX? What data fields should it include?
Finally, once your supplier has produced an SBOM, there’s also the matter of them securely transmitting it to you. There are a few options for SBOM transmission, and it’s important to communicate these requirements to your supplier as well. (FOSSA’s secure SBOM Portal is a popular option for many organizations.)
- Implementing the right tooling
Although it may theoretically be possible for certain (smaller) organizations to manage Requirement 6.3.2 with manual processes and Excel spreadsheets, most PCI entities will need at least some level of automation. The good news is that many existing SCA (software composition analysis) tools also have SBOM capabilities, so you may not need to scramble to implement something new.
However, before finalizing your decision, we do recommend making sure you determine whether your existing tool (or possible new tool under evaluation) supports several essential SBOM management capabilities; these will also go a long way toward helping you with 6.3.2’s testing procedures.
- Maintaining vulnerability remediation documentation
As mentioned, Testing Procedure 6.3.2.a requires organizations to use their component inventory to “identify and address” vulnerabilities. In practice, this means you’ll need to have:
- A list of vulnerabilities associated with the components in your SBOMs
- Documentation with proof of remediation and/or remediation efforts
Here again, there’s no mandated format or structure for a vulnerability list and proof of remediation, but it would be worth considering the use of VEX (Vulnerability Exploitability eXchange) or VDR (Vulnerability Disclosure Report) documents. Both VEX and VDR are intended to be published alongside SBOMs and capture information on vulnerabilities, whether the product is impacted by the vulnerabilities, and mitigation steps. We recommend reading this OWASP blog for a more detailed comparison and guidance on which might be the right format for your team’s needs.
FAQ: PCI DSS SBOM Requirements
What is the SBOM requirement in PCI DSS 4.0?
PCI DSS 4.0 introduces a requirement (6.3.2) that, starting March 31, 2025, every instance of bespoke and custom software must carry an inventory of software components. While not explicitly mandating SBOMs, producing them is considered the most practical way to fulfill this requirement.
Does PCI DSS specify a particular format or set of data fields for SBOMs?
No, PCI DSS does not prescribe a specific format or set of data fields for SBOMs. However, it does require that the inventory includes all payment software components and dependencies, including supported execution platforms, third-party libraries, services, and other required functionalities.
What should organizations do to prepare for the SBOM requirements in PCI DSS?
Organizations can prepare by:
SBOMs and PCI DSS: The Bottom Line
Strengthening software supply chain security and transparency is a growing priority for organizations across a range of industries, and financial services is no different. The SBOM requirements in PCI DSS 4.0 (which are also applicable to 4.0.1) represent another important step in this direction.
FOSSA is currently helping our financial industry customers navigate PCI DSS requirements for SBOMs and vulnerability management, and we welcome you to connect with our experts for additional guidance and recommendations. Fill out the form on this page to get in touch.