PCI DSS 6.2.4: Prevent Common Software Attack Vulnerabilities
Software vulnerabilities are a leading attack vector for payment card data breaches. PCI DSS 6.2.4 requires your organization to implement secure software engineering techniques that systematically prevent or mitigate common attack vectors. This control bridges development practices and security outcomes—ensuring your code is hardened against threats before deployment.
What this means
This control mandates that your organization adopt and enforce defined software engineering techniques and methodologies specifically designed to eliminate or reduce the risk of common software attacks. Common vulnerabilities include injection flaws, broken authentication, sensitive data exposure, XML external entities (XXE), broken access control, security misconfiguration, cross-site scripting (XSS), insecure deserialization, using components with known vulnerabilities, and insufficient logging. Rather than relying on post-deployment security testing alone, 6.2.4 requires proactive threat modeling, secure coding standards, and development practices that build security into the software development lifecycle (SDLC) from the beginning.
How to comply
- 1.Define and document secure software development standards that address common vulnerabilities (OWASP Top 10, CWE/SANS Top 25)
- 2.Establish a secure coding training program mandatory for all developers before they write production code
- 3.Implement code review processes that specifically focus on identifying and remedying security weaknesses
- 4.Integrate static application security testing (SAST) tools into your build pipeline to detect vulnerabilities automatically
- 5.Perform threat modeling during the design phase of new applications and major updates
- 6.Use software composition analysis (SCA) tools to identify known vulnerabilities in third-party libraries and dependencies
- 7.Enforce input validation, output encoding, and parameterized queries across all applications handling cardholder data
- 8.Document which secure engineering techniques are required for each type of application (web, API, mobile, etc.)
- 9.Maintain records of developer training completion and track remediation of identified security issues
- 10.Review and update secure coding standards annually or when new attack vectors emerge
Evidence auditors look for
- Documented secure coding standards or guidelines specific to your organization
- Training records showing all developers completed secure coding training
- SAST tool reports with configuration showing integration into CI/CD pipeline
- Code review checklists that include security vulnerability checks
- Threat modeling documentation for critical applications
- SCA tool reports identifying and tracking remediation of vulnerable dependencies
- Examples of code changes made in response to security findings
- Incident logs showing vulnerabilities identified and patched
- OWASP compliance matrix mapping your practices to OWASP Top 10
- Policy documentation linking development practices to PCI DSS requirements
Frequently asked questions
When will FAQs be available?
The FAQ for this control is currently being prepared.
GRCWatch automates the tracking of developer training completion, consolidates SAST and SCA tool findings into audit-ready evidence, and maintains a compliance matrix linking your secure coding practices directly to 6.2.4—eliminating manual documentation and reducing audit remediation time.
See how GRCWatch handles this control automatically
Start free trial