PCI DSS Compliance Checklist for In-House Code: How to Prepare Requirement 6 Evidence

Requirement 6 of PCI DSS 4.0.1 asks organizations to develop their own software securely, maintain an inventory of the third-party components inside it, and patch critical vulnerabilities within 1 month. 

Since March 31, 2025, all of its requirements are checked during a PCI audit, including the inventory of third-party components (6.3.2). We've covered what each requirement asks for in PCI DSS 4.0.1 Requirements: What a PCI Audit Checks in In-House Code.

This checklist covers the in-house code part of Requirement 6. Here's how to prepare it, step by step.

Define which applications are in scope

Start with a list of in-house applications that store, process or transmit cardholder data, or that connect to systems that do. Include the older ones that are no longer in active development: as long as they run in the cardholder data environment, Requirement 6 applies to them too.

 

Build an inventory of components for every application (6.3.2)

Requirement 6.3.2 asks for an inventory of bespoke and custom software and of the third-party components incorporated into it. In practice, this inventory is an SBOM (software bill of materials) for each application.

DerScanner SBOM generation produces a CycloneDX SBOM directly from source code, for Java, Kotlin, Scala, JavaScript, TypeScript, Python, C#, Go, PHP, Ruby, Rust, Swift, C/C++ and Erlang. For Delphi and Object Pascal applications, we've specifically developed Delphi SCA.

[IMPORTANT] The inventory has to include transitive dependencies (libraries pulled in by other libraries). A list of direct dependencies from a package.json or pom.xml file is not enough to answer whether a vulnerable component is inside the application.

[NOTE] For applications built in a closed network, SBOM generation needs an internal repository manager. We cover it in How to Generate an SBOM in an Air-Gapped Environment.

 

Review the code before every release (6.2.3)

Requirement 6.2.3 asks to review “bespoke and custom software” before it is released into production or to customers, and to fix what the review finds before the release. The review has to check the code against secure coding guidelines and look for both existing and emerging vulnerabilities.

Bottom line, the review has to happen on each release. The most practical way is to run DerScanner SAST in the CI/CD pipeline, so that every build is scanned before it ships. DerScanner integrates with GitLab CI, Azure, Jenkins, and TeamCity, and covers 43 languages, including COBOL, ABAP and Delphi.

 

Make sure the review covers the attack types from 6.2.4

Requirement 6.2.4 lists the attack types that the development techniques have to prevent. DerScanner SAST maps its findings to CWE, so each attack type from the requirement can be matched with the CWE entries that show it is covered.

[NOTE] Findings are also mapped to OWASP Top 10, CWE/SANS Top 25 and PCI DSS 4.0.1, so the same results can be shown grouped by these classifications.

 

Rank vulnerabilities by risk (6.3.1)

Requirement 6.3.1 asks to rank vulnerabilities by risk and to identify, at a minimum, all high-risk and critical ones. This covers both in-house code and third-party components.

Not every vulnerable library is a real risk for a specific application. DerScanner's hybrid SAST and SCA mode traces whether a vulnerable function in a dependency is actually called from the application code. The reachability analysis guide explains the method.

 

Record when each critical vulnerability was fixed (6.3.3)

Requirement 6.3.3 gives 1 month to install critical and high-security patches. To show that this deadline was met, the team needs a record of when a vulnerable component appeared and when the fix shipped.

Scan history in each DerScanner project and Scans Comparison (new, remaining and fixed findings between two scans) show exactly that.

[IMPORTANT] A completed scan doesn't update itself. When a new critical CVE is published, re-scan the affected applications or their saved SBOMs, so the 1-month clock starts from the moment the team actually learns about it.

 

 

PCI DSS checklist for in-house code

 

If you're looking for ways to prepare Requirement 6 evidence on your own codebase, book a demo or request a PoC. We're always up for a chat.