| 💼 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking to newly discovered security vulnerabilities. | | | | |
| 💼 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. | | | 1 | |
| 💼 6.3 Develop internal and external software applications securely. | 2 | | | |
| 💼 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. | | | | |
| 💼 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability. | | | | |
| 💼 6.4 Follow change control processes and procedures for all changes to system components. | 6 | | | |
| 💼 6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls. | | | | |
| 💼 6.4.2 Separation of duties between development/test and production environments. | | | | |
| 💼 6.4.3 Production data (live PANs) are not used for testing or development. | | | | |
| 💼 6.4.4 Removal of test data and accounts from system components before the system becomes active / goes into production. | | | | |
| 💼 6.4.5 Change control procedures. | 4 | | | |
| 💼 6.4.5.1 Documentation of impact. | | | | |
| 💼 6.4.5.2 Documented change approval by authorized parties. | | | | |
| 💼 6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system. | | | | |
| 💼 6.4.5.4 Back-out procedures | | | | |
| 💼 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. | | | | |
| 💼 6.5 Address common coding vulnerabilities in software-development processes. | 10 | | | |
| 💼 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. | | | | |
| 💼 6.5.2 Buffer overflows. | | | | |
| 💼 6.5.3 Insecure cryptographic storage. | | | | |
| 💼 6.5.4 Insecure communications. | | | | |
| 💼 6.5.5 Improper error handling. | | | | |
| 💼 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process. | | | | |
| 💼 6.5.7 Cross-site scripting (XSS). | | | | |
| 💼 6.5.8 Improper access control. | | | | |
| 💼 6.5.9 Cross-site request forgery (CSRF). | | | | |
| 💼 6.5.10 Broken authentication and session management. | | | | |
| 💼 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks. | | | | |
| 💼 6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. | | | | |