A retailer scanning for PCI DSS 4.0 readiness in early 2025 typically discovers the same gap: their custom checkout code has never been mapped against a component inventory, and nobody can say with certainty which of the 340-odd open source packages in their payment application carry a known CVE. That gap is no longer a minor audit footnote. As of March 31, 2025, the PCI Security Standards Council's "future-dated" requirements in PCI DSS 4.0 became mandatory, and several of them — 6.3.2, 6.4.2, 11.3.1.1 — turn application security testing from a periodic checkbox into a continuous, evidence-producing process. Teams evaluating tools like Endor Labs to close this gap are really asking a compliance question first and a tooling question second. Here is what PCI DSS actually requires for application security testing, where the requirement numbers come from, and what "compliant" evidence looks like in practice.
What Does PCI DSS 4.0 Actually Require for Application Security Testing?
PCI DSS 4.0's Requirement 6, "Develop and Maintain Secure Systems and Software," is the section that governs application security testing, and it splits the obligation into three concrete buckets: build-time secure coding, pre-release vulnerability identification, and post-release protection of public-facing applications. Requirement 6.2.4 requires that bespoke and custom software be developed using secure coding techniques that address common vulnerability classes — injection flaws, buffer overflows, insecure cryptographic storage, cross-site scripting, and broken access control, mapped closely to the OWASP Top 10 and relevant CWEs. Requirement 6.2.3 requires code review for custom code changes prior to release to production, either manually by someone other than the code's author or through an automated tool, with any issues remediated before release. Requirement 6.3.1 requires that security vulnerabilities be identified using "reputable outside sources" for vulnerability information (think NVD, GitHub Security Advisories, vendor bulletins) and assigned a risk ranking. Together these three sub-requirements are the backbone of what an assessor checks when validating an application security testing program, and PCI DSS 4.0 replaced the older 3.2.1 wording specifically to make the expectation of ongoing, tool-supported testing explicit rather than implied.
Why Does Requirement 6.3.2 Make an SBOM Non-Negotiable?
Requirement 6.3.2 makes a software bill of materials effectively mandatory because it requires organizations to maintain an inventory of bespoke and custom software, and the third-party software components incorporated into it, specifically "to facilitate vulnerability and patch management." This requirement carried a future-dated effective date of March 31, 2025, giving organizations roughly three years of runway from the March 2022 publication of PCI DSS 4.0 — and that runway has now closed. The inventory has to be kept current, which in practice means updating it whenever a build changes, not annually. The rationale is the same one that drove Log4Shell's blast radius in December 2021: a critical vulnerability (CVSS 10.0) sat four dependency layers deep inside countless payment applications, and organizations without a component inventory spent weeks just figuring out whether they were affected. Requirement 6.3.2 is PCI's answer to that scenario — if you cannot produce a list of every open source component in your cardholder-data-adjacent applications within hours of a new CVE, you cannot meet this control, regardless of how good your code review process is.
What's the Difference Between Pre-Release Code Review and the Requirement 6.4.2 WAF Mandate?
The difference is timing and target: 6.2.3/6.3.1 govern what happens before code reaches production, while 6.4.1 and 6.4.2 govern what protects a public-facing web application after it's live. Requirement 6.4.1 requires public-facing applications to be reviewed at least once every 12 months and after any significant change, either through manual or automated application vulnerability security assessment tools or techniques. Requirement 6.4.2 goes further: as of March 31, 2025, organizations must deploy an automated technical solution — commonly a web application firewall — that continually detects and prevents web-based attacks, with alerts generated and logs retained per Requirement 10. Before 4.0, section 6.6 of PCI DSS 3.2.1 let organizations choose between a WAF and a code review; 6.4.2 removes that either/or framing for the assessment layer and makes continuous automated detection a standing requirement for any application handling cardholder data over the public internet.
How Often Do Vulnerability Scans and Penetration Tests Actually Need to Run?
The cadence is fixed and non-negotiable: quarterly internal scans, quarterly external scans by an Approved Scanning Vendor, and an annual penetration test, with rescans required until high-risk and critical vulnerabilities are resolved. Requirement 11.3.1 requires internal vulnerability scans at least once every three months, and 11.3.1.1 (effective March 31, 2025) requires that any vulnerabilities other than high-risk or critical also be managed per the organization's targeted risk analysis, with rescans to confirm resolution. Requirement 11.3.2 requires external scans at least quarterly, performed by a PCI-approved ASV, with passing results required for compliance. Requirement 11.4.1 requires a penetration test at least annually and after any significant infrastructure or application upgrade. Layered on top of scanning cadence, Requirement 6.3.3 sets a hard patch clock: critical and high-severity vulnerabilities identified per the 6.3.1 risk ranking must be patched within one month (30 days) of identification, with all other vulnerabilities addressed based on the organization's risk assessment. Missing that 30-day window on a critical finding is one of the more common reasons assessors flag a Requirement 6 control as not-in-place.
Where Do Tools Like Endor Labs Fit Into a PCI DSS Program?
Endor Labs fits as a software composition analysis and reachability-analysis platform, and it fits well for reducing developer-facing noise, but it was not built primarily to produce the assessor-facing evidence that Requirements 6.3.2, 6.3.3, and 11.3 demand. Founded in 2021 and backed by a $70 million Series A in 2023, Endor Labs' core differentiator is reachability analysis: instead of flagging every CVE in every transitive dependency, it determines whether the vulnerable function is actually called by the application's code paths, which the company reports can cut the volume of actionable SCA findings dramatically. That's a genuinely useful capability for engineering teams drowning in dependency alerts. But a PCI DSS assessment doesn't just ask "did you triage vulnerabilities effectively" — it asks for a maintained component inventory tied to specific applications (6.3.2), proof that critical fixes landed inside 30 days (6.3.3), and quarterly-cadence scan records mapped to specific requirement numbers that a QSA can walk through during a Report on Compliance. Reachability-focused SCA tools generally leave that compliance-mapping and evidence-packaging layer — SBOM export in CycloneDX or SPDX format, historical audit trails, and requirement-by-requirement reporting — as a gap the compliance team has to fill manually, often by stitching together exports from three or four separate tools.
How Safeguard Helps
Safeguard is built around the assumption that application security testing and compliance evidence are the same artifact, not two separate workstreams. For Requirement 6.3.2, Safeguard continuously generates and versions SBOMs in CycloneDX and SPDX formats for every bespoke and custom application, automatically capturing third-party components at build time so the inventory updates itself instead of relying on a quarterly manual export. For Requirement 6.3.1 and 6.3.3, Safeguard pulls vulnerability data from the same reputable outside sources PCI DSS names — NVD, GHSA, OSV — applies risk ranking, and tracks the 30-day critical-patch clock per component with alerts before the window closes, so a missed SLA shows up as a dashboard finding weeks before it becomes an audit finding. For the scanning cadence in Requirement 11.3, Safeguard's continuous monitoring produces a running record of scan history that maps directly to quarterly internal/external cycles, so evidence collection for a QSA isn't a scramble the week before the assessment. And because Safeguard maps every finding and every SBOM entry back to the specific PCI DSS 4.0 requirement number it satisfies, compliance teams get audit-ready reporting instead of raw vulnerability lists they have to translate themselves. The result is an application security testing program where the SBOM, the vulnerability data, and the compliance report are one continuously updated system — which is precisely what Requirement 6.3.2's "to facilitate vulnerability and patch management" language was written to require.