By
·
3 minute read
This article highlights some of the new PCI requirements around code vulnerabilities reported by security scanners and how to comply with them with minimal effort. It explores how PCI DSS mandates the creation and implementation of a remediation plan, and the consequences of non-compliance in light of the recent PCI DSS v4.0 and its updates in v4.0.1. In addition this article provides practical steps to help organizations comply with the new standards.
What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. Originally introduced to mitigate the risk of data breaches, PCI DSS has undergone several updates over the years to keep pace with evolving security threats. The latest major update to PCI DSS is v4.0, which was released in March 2022 and officially replaced v3.2.1 earlier this year.
Recent Changes in PCI DSS and the Timeline
PCI DSS v4.0 introduced significant changes, including more explicit requirements for addressing vulnerabilities and the inclusion of a customized approach for security controls. In June 2024, PCI DSS v4.0.1 was released to refine these updates, providing additional clarity and addressing feedback from the community. This minor update plays a crucial role in ensuring that organizations have a clear path to compliance while adapting to the new standards. The transition period allows organizations time to adjust to these changes, culminating on March 31, 2025, when full enforcement begins. By this date, all organizations must fully comply with the requirements outlined in v4.0 and v4.0.1, including the rigorous guidelines on vulnerability remediation.
Every Vulnerability is a Risk
PCI DSS v4.0.1 leaves little room for ambiguity when it comes to remediating identified source code vulnerabilities. It explicitly states, "All vulnerabilities, regardless of criticality, provide a potential avenue of attack and must therefore be addressed periodically" (Requirement 11.3.1.1). Whether or not low and medium severity vulnerabilities are seen as real risks, PCI DSS mandates that all vulnerabilities must be addressed. Ignoring this can lead to serious compliance and security repercussions.
Audit Implications Are Real
Skipping over some findings or avoiding the verification of claimed mitigations comes with consequences. PCI DSS is clear about the implications of not addressing vulnerabilities and outlines how auditors should assess vulnerability management practices. Specifically, Requirement 11.3.1.1.b mandates that “… all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities…) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed.”
Failure to comply can result in extended audits, increased scrutiny, and potential fines. In short, the risk of failing an audit now adds to the danger of a potential data breach.
Timeline for Fixing Vulnerabilities: A Moving Target
The transition from PCI DSS v4.0 to v4.0.1 clarified how organizations should handle vulnerability remediation timelines. Initially, PCI DSS v4.0 suggested more aggressive timelines for fixing vulnerabilities, urging organizations to address high-risk vulnerabilities as soon as possible, sometimes within 30 days.
However, in v4.0.1, these recommendations were adjusted to offer more flexibility, recognizing that different environments may require different approaches. Despite this flexibility, the core message remains: timely remediation is non-negotiable. Organizations must still prioritize and document their approach to vulnerability management, ensuring that any delays are justified and mitigated.
Comprehensive and Proactive Measures Are Required
So, what is the solution? First, organizations must prioritize the remediation of all source code findings, not just the ones deemed important. PCI DSS considers them all potential risks.
Second, quick action is essential. Although March 31, 2025, may seem far off, manually fixing vulnerabilities takes time. According to this Google research, remediating vulnerabilities takes Google developers an average of 2 hours per issue; look at your security backlog and do the math.
Third, robust documentation is necessary. PCI DSS requires clear evidence that all identified vulnerabilities have either been remediated or justified if left unresolved.
Conclusion: Compliance Isn't Optional
Adhering to PCI DSS is not just a recommendation — it is a requirement. Failure to promptly remediate all source code findings can lead to serious consequences, including failed audits, financial penalties, and, worst of all, a data breach. An organization's security and compliance posture depends on the ability to act swiftly and decisively in addressing these vulnerabilities. The stakes are high, and the path forward is clear: remediate, document, and stay compliant.
How Mobb Can Help with These PCI Challenges
Addressing the challenges of PCI DSS compliance, especially with the upcoming 2025 deadline, can be daunting. Mobb offers automatic remediation for source code vulnerabilities, helping organizations tackle their security backlog at scale, efficiently and effectively. By automating the remediation process, Mobb ensures that vulnerabilities are addressed promptly, reducing the risk of non-compliance and making it easier to meet PCI DSS requirements. To see how Mobb can support your compliance efforts, sign up for a demo here.
Don’t let a backlog of unaddressed vulnerabilities put your company at risk — address them now before it’s too late.
DDFFFFFFF
Eitan Worcel