PCI DSS 6.3.2: An inventory of bespoke and custom software, and third-party software components incorporated
PCI DSS v4.0.1 control 6.3.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.3.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.3
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.
Summary
Keep an inventory of the software you had written and the third-party components inside it, so you can tell which of your applications a new vulnerability affects.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 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. |
This is not the system inventory in 12.5.1. It is a bill of materials for code: the bespoke and custom software you run, plus the libraries, frameworks and packages compiled or bundled into it. The purpose is stated in the control text itself, "to facilitate vulnerability and patch management", and procedure 6.3.2.a tests that the inventory is used to identify and address vulnerabilities. An inventory nobody consults fails. It is also what makes 6.3.1 actionable: you cannot rank an advisory by how much it matters to your environment if you do not know which of your applications ships the affected library.
What to prepare
- The inventory itself, covering every bespoke and custom application and the third-party components in each.
- Evidence that it is used, such as a vulnerability triage record naming the affected application from the inventory.
- Documentation for one or two applications, so the assessor can compare what they include against what the inventory records.
How to implement it
1. Generate it from the build, do not maintain it by hand. Lockfiles and an SBOM produced during CI (CycloneDX or SPDX) are current by construction. A spreadsheet is accurate on the day it is written.
2. Include transitive dependencies. The vulnerabilities that matter are usually several levels down, and a list of direct dependencies will not find them.
3. Record the version, not just the component. An inventory that says an application uses a library, without saying which version, cannot answer the only question it exists to answer.
4. Wire it to the intake in 6.3.1. The test is whether an advisory can be turned into a list of affected applications, so make that lookup something you can demonstrate.
Where this commonly fails
- A list of applications with no components, which records what you run and not what is in it.
- Direct dependencies only, so a vulnerability in a transitive package is invisible.
- An inventory produced once for the assessment and not regenerated as the software changes.
- Bespoke software written by a third party for you left out, because it was thought of as a vendor product rather than as custom software.
Related controls
Others in section 6.3:
| Control | What it requires |
|---|---|
| 6.3.1 | Security vulnerabilities are identified and managed… |
| 6.3.3 | All system components are protected from known vulnerabilities by installing applicable… |
← 6.3.1 · All controls · 6.3.3 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.