PCI DSS 4.0 Requirement 6 — what secure software teams must meet

PCI DSS v4.0 replaced v3.2.1 as the only active standard in March 2024, and the future-dated requirements that were best practice during the transition became mandatory on 31 March 2025. For any team handling cardholder data, Requirement 6 — "Develop and maintain secure systems and software" — is where engineering work now has to produce evidence, not just intent.

What Requirement 6 actually asks for

Requirement 6 covers the software lifecycle and the vulnerability management that wraps around it. The parts that most often surprise engineering teams:

• 6.2 — secure development. Software is developed against secure-coding guidance, and developers are trained on the vulnerabilities relevant to the languages and frameworks they ship.
• 6.3 — identifying vulnerabilities. Both bespoke code and third-party and open-source components are tracked, and newly disclosed vulnerabilities are assigned a risk ranking so the urgent ones surface above the noise.
• 6.3.2 — a software inventory. You maintain an inventory of bespoke and custom software, plus the third-party components it depends on, to support vulnerability management. In practice this means a usable bill of materials.
• 6.4.3 / 6.4.2 — public-facing web applications. Scripts on payment pages are inventoried and authorized, and web applications sit behind an automated technical solution that detects and prevents web-based attacks.

The shift from v3.2.1 is one of emphasis: v4.0 expects continuous, evidenced management of software risk rather than a point-in-time snapshot, and it leans on the "customized approach" so teams can meet the objective with controls that fit their stack.

Where the work usually lands

Most of the friction is not the policy — it is mapping these clauses onto a real codebase. Which components are actually in use, which have known vulnerabilities, what risk ranking applies, and what is already logged or controlled. Assembling that picture by hand across repositories is where deadlines slip.

Where a scan helps

OLYDI fingerprints the stack and surfaces the components, known-vulnerability findings, and control gaps that map to Requirement 6 — dependency and software inventory, vulnerability identification, and the boundaries around your public-facing surfaces — as findings you can triage in the Security tab. It does not assess or certify you against PCI DSS; a Qualified Security Assessor does that. What it gives you is a baseline read of where you stand, so the assessment conversation starts from evidence rather than a blank page.

Get your baseline

npx @olydi/cli scan
# Scan complete. Findings written to SARIF.

Run the scan, review the findings, and decide what to clear first. The scan is free; clearing findings at volume is paid on Valty tiers.

This article is general information about regulatory developments, not legal advice. Consult qualified counsel for your specific obligations.