In November’s update to PCI DSS, now on version 3.0, you may have noticed that the PCI Security Council switched the order of the first two application security focused sub-requirements. Requirement 6.1 now focuses on establishing ongoing best practices, while 6.2 moves on to patching and remediation efforts. Some of our customers have questioned the logic of such a small change, so I thought we should cover it in a blog post! The new guidance to 6.1 recognizes the need to prioritize and rank your vulnerabilities prior to executing a remediation or mitigation plan and encourages enterprises to remain aware of new vulnerabilities that may threaten their systems and ultimately disrupt “business-as-usual.” In conjunction with the guidance in 6.1, 6.2 urges enterprises to build a process by evaluating risks and prioritizing patch cycles on the most critical systems within 30 days, and less business critical systems within 2 to 3 months following a patch release. We all know you can’t fix everything right away, but this approach ensures that all systems will get patched, not just the most critical ones. Let’s face it, as new application languages, architectures, and platforms are introduced and adopted, new vulnerabilities are sure to follow. And as enterprises evolve to close the gap those vulnerabilities pose, hackers will shift tactics and find new ways to exploit them. History does have a way of repeating itself, especially when it’s an arms race. Since applications will always be choice targets for hackers, understanding what the threat landscape is before you decide how to tackle it should be the first step toward developing an ongoing process you can be proud of, rather than checking the compliance box once a year. From the very beginning, the CA Veracode platform was designed to make remediation efforts for the sake of compliance as straightforward as possible. Our ‘Fix First Analyzer’ organizes internal and third-party scan results into actionable data for developers (yes developers!) to consume. Flaws identified in the code are prioritized based on the severity level, but also by the effort to fix, and the exploitability of the flaw, all according to the OWASP Top 10, and/or SANS Top 25 CWE definitions. Developers are presented with a visual and navigable map to help determine which vulnerabilities pose the greatest risks and should be remediated soonest, including remediation advice on how to go about addressing each flaw. While earlier versions of the standard stressed the importance of patching, this revision to PCI DSS moves toward the adoption of an application security process rather than a one-time step on the way to compliance. The only way to achieve true security is to never give up on the applications…well, until you end-of-life them. The tools you need to help comply with application security requirements found in PCI DSS 3.0 are just a cloud away.