How to Pass a PCI DSS Audit When Running EOL Open Source Software

What PCI DSS Says About EOL Software

PCI DSS v4.0 Requirement 6.3 (Develop and Maintain Secure Systems and Software) contains the controlling requirement for EOL open source in payment environments. Specifically:

Requirement 6.3.3: "All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: Critical patches/updates are installed within one month of release. All applicable security patches/updates are installed within an appropriate timeframe as determined by the entity's risk assessment."

For EOL open source software, the phrase "installing applicable security patches/updates" is the crux of the issue. When a CVE is disclosed against an EOL version and the upstream project does not release a patch for that version, there is no "applicable security patch/update" to install — unless a third party provides one.

Running EOL PostgreSQL, RabbitMQ, Kafka, or Spring Framework with disclosed unpatched CVEs is a direct Requirement 6.3.3 finding. QSAs document it. The cardholder data environment's PCI DSS certificate is affected.

How QSAs Evaluate EOL Software

Qualified Security Assessors assess EOL software differently depending on context:

Scenario 1: EOL software with no CVEs currently disclosed

Many QSAs will allow this with appropriate compensating controls documented in the ROC (Report on Compliance), along with a remediation timeline. The key is documentation: the entity must demonstrate awareness of the EOL status, monitoring for new CVE disclosures, and a defined migration timeline.

Scenario 2: EOL software with disclosed, unpatched CVEs

This is a finding. Compensating controls may be considered but are harder to justify when an exploitable vulnerability exists in a component of the CDE. Most QSAs require either patching evidence or a very specific technical compensating control (network isolation, WAF rules, etc.) that demonstrably addresses the specific vulnerability.

Scenario 3: EOL software with third-party patches applied

Third-party patches from a vendor like OSSeva, with documented CVE attestation letters and CVSS evidence, are generally accepted by QSAs as satisfying Requirement 6.3.3 for the specific CVEs addressed. The assessor looks for: patch source verification, build signing (OSSeva provides GPG-signed artifacts), regression testing evidence, and documentation of what was patched and when.

What Documentation Does OSSeva Provide for PCI Audits?

OSSeva Assure provides a PCI DSS-specific compliance package with each patch cycle:

• CVE attestation letters: Per-CVE documentation identifying the vulnerability ID, CVSS score, affected version, patch delivery date, patch source, and OSSeva's attestation that the vulnerability has been remediated in the delivered build.
• Patch cadence evidence: A log of all patch deliveries with dates, satisfying QSA questions about whether the entity's 30-day critical patch SLA was met.
• Build provenance: GPG-signed artifacts with SHA-256 checksums, enabling QSAs to independently verify that deployed builds match the OSSeva-provided patched build.
• Requirement 6.3 mapping matrix: A table mapping each CVE addressed to the specific PCI DSS Requirement 6.3 sub-requirement, formatted for direct submission to QSA teams.

The 30-Day Patch Window Requirement

PCI DSS Requirement 6.3.3 specifies that critical patches are installed within one month. For EOL open source, OSSeva's Critical CVE SLA (CVSS ≥ 9.0) under OSSeva Operate is 72 hours from confirmation, and high-severity patches are delivered within two weeks. This consistently meets the 30-day PCI DSS window with significant margin, and OSSeva provides timestamped delivery records for QSA review.

Compensating Controls for EOL Software

If an immediate patch is not available, PCI DSS Appendix B provides a compensating controls framework. The compensating control must meet the intent of the original requirement and provide an equivalent level of defense. For EOL software, common compensating controls include:

• Network isolation of the system from other CDE components
• WAF or IDS rules specifically blocking exploitation attempts for the disclosed CVE
• Increased logging and monitoring focused on indicators of exploitation
• Expedited migration timeline with board-level approval

Note that compensating controls are evaluated per-CVE by the QSA. A WAF rule that blocks the specific exploit for CVE-XXXX-YYYY may satisfy a compensating control for that specific CVE, but it does not satisfy the requirement broadly — the next disclosed CVE would require a new compensating control analysis. Extended lifecycle support with active patching is typically a more sustainable approach.

A Note on Self-Assessment vs. QSA-Assisted Assessment

Merchants completing SAQ (Self-Assessment Questionnaire) are sometimes more lenient with themselves on EOL software findings than QSAs would be in a formal assessment. If your organization is moving from SAQ to QSA-assisted assessment — common as companies grow or as payment volume increases — previously tolerated EOL software will become formal findings. It's worth addressing proactively.