What’s new in PCI DSS v4.0
PCI DSS is a set of security requirements designed to protect sensitive cardholder data, such as credit card information, expiration, name, etc. All organizations which store, process, or transmit cardholder data must adhere to the requirements.
PCI DSS v4.0 is the latest version of the security requirements which are effective starting April 1, 2024 and required after April 1, 2025. Among many of the updates to the requirements, there are enhanced guidelines around how organizations detect, manage, and remediate their vulnerabilities.
Vulnerability management requirements in PCI DSS v4.0
Continuously detect and prioritize new vulnerabilities
Organizations are required to scan for vulnerabilities once every three months and make sure all vulnerabilities are triaged.
- Requirement 11.3.1 — Internal vulnerability scans are performed once every three months at least
- Requirement 11.3.1.1 — All applicable vulnerabilities (in addition to high-risk or critical per the entity's vulnerability risk rankings defined at Requirement 6.3.1) are addressed.
All vulnerabilities must be ranked based on risk
This requirement prompts organizations to look at industry based practices for classifying vulnerabilities and to create their own classifying system to rank all vulnerabilities discovered by their scanner. There are special call outs to catalog and classify vulnerabilities found in third-party software as well (requirement 6.3.2).
- Requirement 6.3.1 — New security vulnerabilities are identified using industry-recognized sources for security vulnerability information. Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. Vulnerabilities for bespoke and custom, and third-party software (for example, operating systems and databases) are covered.
- Requirement 6.3.2 — An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
Fix all critical and high vulnerabilities, have a plan of action for the rest. Once vulnerabilities and security weaknesses are detected and classified, organizations must address all vulnerabilities based on their classification. This is a change from the previous PCI DSS guidelines where only critical and high vulnerabilities must be addressed. Requirement 11.4.4 — All exploitable vulnerabilities and security weaknesses must be addressed based on your remediation policy, as defined in 6.3.1.
Challenges with the new vulnerability management requirements
Vulnerability scanners can be noisy
Many scanners produce false positives or report vulnerabilities which aren’t actually risky. With requirement 11.4.4, all vulnerabilities must be investigated and a justification must be provided for any vulnerabilities which aren’t applicable. As a result, organizations must tune their scanners for a specific application for the best results, or run multiple scanners to correlate findings and ensure you’re picking up true positives only.
Vulnerability remediation plans can be difficult to implement
Executing on a plan to remediate vulnerabilities across all your software can be very complex. For example, organizations must test whether the fix will *actually* remediate the vulnerability, as sometimes it may introduce another greater risk to your software. Next, organizations must catalog and validate all applications which need to be remediated which may involve several teams and further application-specific testing to make sure everything works as expected.
High human cost
AppSec or Product Security teams will likely be the owner to detect, investigate, and determine the appropriate remediation. With the update in requirement 11.4.4 where all vulnerabilities must be addressed (instead of critical and high only), the team’s responsibilities will increase drastically. Just considering the golang:latest image, there are 26 critical/high vulnerabilities among a total of 128 vulnerabilities (as of May 12, 2024). This image alone represents an increase of almost 4x in vulnerabilities to address for Product Security teams.
Get PCI DSS v4.0 compliant quickly with Chainguard Images
Chainguard Images are carefully engineered to contain low-to-no CVEs. Organizations can use them as their source to build their applications on. The benefits of our solution are:
- You’re secured by default — our Images contain low-to-no CVEs. Check out our Images Directory yourself.
- Extensive scanner partnerships — we partner with the industry-leading scanners such as Snyk, Crowdstrike, and Wiz just to name a few
- SBOM for all Chainguard Images — get full transparency into the packages actually used in our images and ultimately run in your environment.
- Less ongoing human overhead — every new Chainguard Image version is carefully scanned and any addressable CVEs are fixed.
- Trust in our industry leading CVE SLA — we are committed to supplying secure software and commit to fixing CVEs so you don’t have to.
Chainguard offers zero-known CVE Images for popular projects such as python, go, and nginx just to name a few. Check out our Images Directory to try our images for free today.
*Special thanks to the Chainguard Sales Engineering team for sharing their deep knowledge of PCI DSS v4.0. Their insights were instrumental in shaping the content of this post and ensuring its accuracy.
