Seal Security raises $13M series A to secure open source code at scale. Read full press release.
.avif)
PCI DSS 4.0 is the latest version of the Payment Card Industry Data Security Standard, released to enhance how organizations secure credit card data. It replaced PCI DSS 3.2.1 as of April 1, 2025. PCI DSS 4.0 places a stronger emphasis on continuous vulnerability management, requiring organizations to adopt a more rigorous and proactive approach. It introduces updated security controls, increased flexibility, and a stronger focus on continuous compliance.
Notable changes are highlighted in Requirement 6 and 11. These changes include:
Parties involved in compliance include card brands and networks such as Mastercard, Visa, JCB International, and American Express, and payment gateway and handling services such as PayPal, Stripe, and Square.
Compliance is contractually enforced by major card brands and acquiring banks, meaning you’re at risk of fines and higher transaction costs if you don’t comply. You are not legally required to be PCI compliant, and it’s not enforced by government agencies or the PCI SSC.
However, non-compliant companies risk civil legal action if card data is leaked and may come under greater scrutiny from data regulators – for example, those ensuring firms adhere to DORA, CCPA, and GDPR.
Level 1 (Highest): Merchants that process more than six million total combined Mastercard and Maestro transactions annually or meet Visa’s level 1 standards.
Level 2: Merchants that process between one and six million transactions annually or meet Visa’s level 2 standards.
Level 3: Merchants with over 20,000 annual Mastercard and Maestro transactions via e-commerce but fewer than one million.
Level 4 (Lowest): Applies to all other merchants that don’t fit in the above categories
Yes, If you store cardholder data post-authorization or qualify for certain SAQs, then you must complete a passing scan every 90 days by a PCI SSC Approved Scanning Vendor (ASV). Results must be submitted to your acquirer as proof of compliance.
What Is Requirement 6? How does it relate to Open Source Security?
For Requirement 6, organizations must develop and maintain secure applications. This requirement focuses on identifying and addressing vulnerabilities in custom, third-party software, operating systems, and databases. It includes three critical sub-requirements:
Requirement 6.3.1: Organizations must identify and manage new security vulnerabilities using industry-recognized sources and rank them by risk based on best practices and potential impact.
Requirement 6.3.2: An inventory of bespoke and custom software, as well as third-party software components incorporated into custom software, must be maintained.
Requirement 6.3.3: Critical or high-severity patches and updates must be installed within one month of release.
With regards to open source, 6.3 goes beyond just identifying and prioritizing vulnerabilities. Organizations have one month to patch the CVEs. This is challenging for most organizations when responsibility falls upon developers to remediate first party and open source vulnerabilities.
Noncompliance with Requirement 6.3.3 can lead to:
Seal Security goes beyond identifying and prioritizing open source vulnerabilities and delivers backported, package-level patches for publicly known CVEs at the application and OS layers without introducing breaking changes and upgrades. Seal can also find and fix CVEs in legacy codebases and EOL systems. We also offer secure base images for containers and VMs that are continuously maintained and kept free of known CVEs. Learn More
If a new CVE is discovered, Seal has a 72 hour SLA for patches for critical and high-severity open source CVEs. With regards to Requirement 6.3, Seal’s approach to finding and fixing open source CVEs at the application, OS, and base image layers allows organizations to meet the requirements for 6.3.1, 6.3.2, and 6.3.3. In particular, the 30-day patching timeline for critical and high-severity CVEs stated in section 6.3.3.
Requirement 11 focuses on regular testing and vulnerability management across systems, applications, and networks. It introduces several sub-requirements that strengthen how organizations detect and respond to risks:
Requirement 11.3.1: Run vulnerability scans at least every three months and prioritize remediation based on risk, with urgent attention to high- and critical-severity issues.
Requirement 11.3.1.1: Perform targeted risk analyses for non-critical vulnerabilities to decide whether to remediate or just accept the risk.
Requirement 11.3.1.2: Conduct automated scans after significant changes, making vulnerability management continuous and aligned with CI/CD workflows.
Requirement 11.3.1.3: Perform internal scans after major changes to network or system components to identify any new exposures.
Seal can integrate with your existing SCA tools, source code management repositories, and Linux OS and automatically detect, track, and fix open source components in real time. This will allow your organization to shift security from a reactive, prioritization-driven process to a proactive, comprehensive remediation strategy and meet the 30-day remediation timeline for critical and high-severity CVEs.
Seal supports patching across:
Seal Security enables your team to meet PCI DSS 4.0 patching requirements—without upgrades, delays, or added developer burden.
Book a demo to see how Seal delivers automated compliance-grade remediation for your open source stack.
.png)
