PCI-DSS v4.0 Requirements That Live in Your Code, Not Your Network
PCI-DSS v4.0 has been the only valid revision since March 2025. Requirements 6.2 and 6.3 are the ones developers own, and they are stricter than v3.2.1 in ways most teams have not yet absorbed.
Meet PCI-DSS v4.0 requirements 6.2-6.4 in code
- Enable write-time scanning to satisfy Req 6.2.4. Configure your scanner to surface findings as code is written, not on commit or in CI. 'Before the code becomes part of production software' is the requirement. Pre-commit detection is the only durable way to meet it.
- Configure transitive dependency scanning for Req 6.3.3. Enable full graph traversal (including transitive dependencies and shaded JARs). Match against a current CVE catalog and produce documented triage or remediation records for every flagged dependency.
- Add automated SAST/DAST to the pipeline for Req 6.4.1. Annual application-security specialist review is one valid path; automated SAST/DAST coverage on every public-facing change is the other. The automated path scales; the human-only path does not.
- Generate SARIF evidence with PCI control mapping. Export findings annotated with their PCI requirement number (6.2.4, 6.3.3, 4.2.1, 8.3.6, and so on). QSAs sample evidence. Clean per-finding mapping accelerates the assessment.
- Track CWE → PCI mappings as living artifacts. Use a scanner preset that maps the high-frequency CWEs (CWE-89, CWE-79, CWE-312, CWE-319, CWE-798) to their PCI requirement homes. The preset stays in sync with v4.0 reorganizations as PCI SSC publishes updates.
PCI-DSS v4.0: What Developers Actually Own
PCI-DSS v4.0 became the only valid version as of March 31, 2025. The transition from v3.2.1 introduced 64 new requirements, and a meaningful subset live in software. Not in network segmentation or HSMs.
Requirement 6.2: Bespoke and Custom Software
6.2.1 requires all bespoke (custom-built) software to protect against known vulnerabilities by incorporating security in the software development lifecycle. This is not new, but PCI-DSS v4.0 6.2 adds specificity that v3.2.1 lacked:
- Training must be role-specific and current (not a one-time annual checkbox)
- Code review must cover security techniques "aligned to the OWASP guidelines or equivalent"
- Automated scanning must be part of the SDLC for significant changes
6.2.4 is the requirement most teams miss: processes must detect and address common software vulnerabilities before the code becomes part of production software. "Before" is the operative word. This is a write-time or pre-commit requirement, not a post-deploy scan.
Requirement 6.3: Security of Pre-built Software
6.3.3 requires all software components (libraries, frameworks, dependencies) to be protected from known vulnerabilities. All components must be under a security patch policy with tracking of vulnerability exposure and time-to-remediation.
This maps to CWE-1352 (Vulnerable and Outdated Components) and requires more than "we have Dependabot". It requires documented triage, risk acceptance, or remediation for every flagged dependency.
Requirement 6.4: Public-Facing Web Applications
6.4.2 requires an automated technical solution that detects and prevents web-based attacks, but 6.4.1 requires a review by an application security specialist or automated solution at least annually and after any significant change. "Automated solution" here includes SAST/DAST tooling.
The CWE Mapping for PCI-DSS v4.0
The most common PCI-DSS findings map to:
- CWE-89 (SQL Injection) → Req 6.2.4, 6.3.3
- CWE-79 (XSS) → Req 6.2.4
- CWE-312 (Cleartext Storage of Sensitive Information) → Req 3.5.1
- CWE-319 (Cleartext Transmission) → Req 4.2.1
- CWE-798 (Hardcoded Credentials) → Req 8.3.6
How Deva Addresses PCI-DSS v4.0
Deva's PCI-DSS v4.0 preset covers all code-relevant requirements. Req 6.2.4 is addressed by write-time detection. Findings surface as you type, not post-deploy. The scan runs before code reaches production, which is the explicit requirement.
For Req 6.3.3, Deva's supply chain scanner tracks your dependency tree against 27K CVEs and surfaces findings with PCI-DSS control references so your triage records are compliance-annotated from the start.
Frequently asked questions
When did PCI-DSS v4.0 become mandatory?
What is PCI-DSS Req 6.2.4?
What does PCI-DSS v4.0 require for dependencies?
Does PCI-DSS v4.0 require automated security scanning?
Deva Security Team
Threat research, application security analysis, and defensive engineering insights from the DevSecCode team.
Related Articles
HHS Wants Annual Pentests in the HIPAA Security Rule. Here's What That Looks Like.
HHS proposed updates to the HIPAA Security Rule in early 2025 that would make penetration testing an explicit requirement for covered entities. Here's what the proposed rule says and how to prepare.
Read moreCMMC Level 2 Is Enforced. Here's What Your Code Has to Show.
CMMC 2.0 Level 2 enforcement is active for DoD contracts. Most compliance failures trace back to code, not policy. Here's the control mapping every developer on a defense program needs to understand.
Read moreNIST CSF 2.0: Govern Got the Headlines, ID.AM-07 Will Cost You the Audit
NIST released Cybersecurity Framework 2.0 with a new Govern function and expanded scope beyond critical infrastructure. Here's what the update means at the code level.
Read more