PCI DSS 4.0.1 Requirements: What a PCI Audit Checks in In-House Code

PCI DSS 4.0.1 replaced the previous 4.0 version and on March 31, 2025 all requirements became mandatory. This means that 2026 is the first full audit cycle where a Qualified Security Assessor (QSA) checks ALL PCI DSS 4.0.1 requirements.

 

PCI DSS applies to every organization that stores, processes or transmits cardholder data:

• merchants 

• payment processors 

• banks and their service providers. 

And for those that develop their own software, Requirement 6 is where an audit looks at the code.

 

What does Requirement 6 cover?

Requirement 6 is called "Develop and Maintain Secure Systems and Software". The part about in-house code applies to software that the organization develops itself or that a third party develops specifically for them. The standard calls it “bespoke and custom software”.

 

[NOTE] Requirement 6.3.2 has been checked during audits only since March 31, 2025.

 

Why does in-house code raise the most questions?

For a commercial product, the vendor delivers patches and security bulletins. But for in-house code, the organization is the vendor, so it has to do the whole security check itself: review the code, find the vulnerabilities and fix them.

And the third-party components inside this code make the task even harder. A typical application pulls dozens of open-source libraries, and each of them brings its own dependencies (transitive dependencies). Requirement 6.3.2 asks for an inventory of all of them, and requirement 6.3.3 gives 1 month to install a critical patch.

[IMPORTANT] Without a component inventory, a team can't tell whether a critical vulnerability in a library affects its applications or not. In 2021, Log4Shell showed how long such a search can take: many vendors spent weeks establishing where the Log4j library was bundled.

 

 

Here are 3 common mistakes that make audit harder:

• Code review exists only on paper. Pull request approvals show that someone looked at the code, but they don't show that the review checked for the attack types listed in 6.2.4.

• The inventory covers only direct dependencies. A list of libraries from a package.json or pom.xml file misses the transitive dependencies, which is where vulnerable components are often found.

• Older applications fall out of the process. Code review and scanning are usually set up for applications in active development. But an application that hasn't changed for years still processes cardholder data and still needs an inventory and patches.

 

How can in-house code be prepared for the audit?

Requirement 6 doesn't name specific tools, so the organization decides how to meet it. Here's how DerScanner helps provide evidence for it:

1. Code review before release (6.2.3, 6.2.4). DerScanner SAST analyzes source code in 43 languages, from Java and C# to COBOL, ABAP and Delphi, and maps the findings to OWASP Top 10, CWE/SANS Top 25 and PCI DSS 4.0.1. These classifications cover the attack types from 6.2.4: injections, buffer issues, weak cryptography, XSS, CSRF and broken access control.

2. Component inventory (6.3.2). DerScanner SBOM generation produces a CycloneDX SBOM directly from source code, transitive dependencies included. And DerScanner SCA checks these components for known vulnerabilities.

3. Proof of patch timing (6.3.3). Scan history and Scans Comparison (new, remaining and fixed findings between two scans) show when a vulnerable component appeared in the application and when it was fixed.

We've put all these steps into one checklist in PCI DSS Compliance Checklist for In-House Code: How to Prepare Requirement 6 Evidence.

 

 

If you're preparing for a PCI audit and want to test DerScanner on your own codebase, book a demo or request a PoC. We're always up for a chat.