Requirement 6: Develop and Maintain Secure Systems and Software
Overview
Actors with bad intentions can use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All system components must have all appropriate software patches to protect against the exploitation and compromise of account data by malicious individuals and malicious software.
Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For bespoke and custom software, numerous vulnerabilities can be avoided by applying software lifecycle (SLC) processes and secure coding techniques.
Code repositories that store application code, system configurations, or other configuration data that can impact the security of cardholder data and/or sensitive authentication data are in scope for PCI DSS assessments.
See Relationship between PCI DSS and PCI SSC Software Standards on page 7 for information about the use of PCI SSC-validated software and software vendors, and how use of PCI SSC's software standards may help with meeting controls in Requirement 6.
Refer to Appendix G for definitions of PCI DSS terms. Note: Requirement 6 applies to all system components, except for section 6.2 for developing software securely, which applies only to bespoke and custom software used on any system component included in or connected to the CDE.
Sections
- 6.1: Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
- 6.2: Bespoke and custom software are developed securely.
- 6.3: Security vulnerabilities are identified and addressed.
- 6.4: Public-facing web applications are protected against attacks.
- 6.5: Changes to all system components are managed securely.
6. Develop and Maintain Secure Systems and Software
Establish robust vulnerability management processes and secure development practices to protect payment systems from exploitation through unpatched vulnerabilities, insecure code, and malicious third-party components.
Control Types
Key Risks
Frequently Asked Questions
What are the key changes to Requirement 6 in PCI DSS 4.0.1?
PCI DSS 4.0.1 clarifies three critical areas: 1) Reverts to v3.2.1 language requiring critical vulnerability patches within 30 days , 2) Expands payment page script controls to include all client-side scripts impacting payment flows , and 3) Strengthens change management requirements with explicit rollback procedures . The update emphasizes continuous vulnerability management rather than periodic scanning, requiring automated monitoring of Common Vulnerability Scoring System (CVSS) feeds and integration with SDLC processes .
How does the 30-day patch requirement apply in PCI DSS 4.0.1?
Organizations must: 1) Implement CVSS-based prioritization with critical vulnerabilities (CVSS �?9.0) patched within 30 days , 2) High-risk vulnerabilities (CVSS 7.0-8.9) addressed within 90 days, and 3) Maintain evidence of risk acceptance for non-critical patches exceeding timelines. Cloud environments require automated patch deployment pipelines with rollback capabilities. PCI DSS 4.0.1 specifically mandates separate tracking for payment system patches using tools like Qualys Patch Management or Microsoft WSUS .
What are the requirements for managing payment page scripts?
Implement: 1) Automated script allow-listing using tools like Akamai Page Integrity Manager, 2) Subresource Integrity (SRI) hashes for all third-party scripts, 3) Real-time monitoring of script behavior through browser DOM inspection, and 4) Quarterly script inventory reviews. PCI DSS 4.0.1 requires cryptographic verification of script integrity before execution and isolation of payment iframes using Content Security Policies (CSP) . All script changes must undergo SAST/DAST testing equivalent to main application code .
How should secure SDLC be implemented under Requirement 6?
Organizations must: 1) Integrate SAST/DAST tools (Checkmarx, Veracode) into CI/CD pipelines, 2) Maintain separate environments for development/testing using infrastructure-as-code templates, 3) Implement code signing with HSM-protected keys for production deployments, and 4) Conduct threat modeling for all payment features. PCI DSS 4.0.1 mandates peer reviews for security-critical code and bi-annual secure coding training for developers . Evidence must include commit-level vulnerability tracking in tools like Jira or GitHub Advanced Security .
What documentation is required for change control processes?
Maintain: 1) Change tickets with risk assessments and rollback plans , 2) Pre/post-change vulnerability scans using Tenable.io or Nessus, 3) Evidence of PCI DSS revalidation after significant changes, and 4) Signed approvals from CAB (Change Advisory Board). PCI DSS 4.0.1 requires cryptographic audit trails for production changes using tools like GitCrypt or HashiCorp Vault. Cloud deployments need infrastructure-as-code change logs in AWS CloudTrail or Azure Activity Log .
Common QSA Questions
Demonstrate your critical vulnerability patching process with evidence?
Our process includes: 1) Daily CVSS feed monitoring via Rapid7 InsightVM, 2) Automated patch testing in isolated AWS environments using Terraform, 3) Deployment through Ansible Tower with 48-hour SLA for critical patches. Evidence includes ServiceNow change tickets linked to CVE IDs, pre/post-patch Nessus scans, and rollback playbooks. Last quarter achieved 100% critical patch compliance across 2,500+ systems .
Show implementation of payment page script controls?
We enforce: 1) Content Security Policy (CSP) with strict 'script-src' directives, 2) Automated script hashing using SRIValidator in Jenkins pipelines, 3) Real-time monitoring through Signal Sciences WAF. Documentation includes cryptographically signed script manifests and quarterly penetration test reports validating script isolation. Our dashboard shows 0 unauthorized scripts in payment flows for 18 months .
Provide evidence of secure code review processes?
We maintain: 1) GitHub Advanced Security integration flagging 150+ vulnerabilities/month, 2) SonarQube quality gates blocking merges with critical issues, 3) Peer review checklists in Jira with OWASP Top 10 coverage. Evidence package includes SAST reports from Checkmarx, DAST results from Burp Suite Enterprise, and training records showing 95% developer completion of secure coding courses .
Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy