If your organization stores, processes, or transmits cardholder data, PCI DSS application security requirements are no longer a checkbox exercise. PCI DSS 4.0, which became fully enforceable on March 31, 2025, rewired Requirement 6 around continuous application security testing rather than annual scans. Merchants and service providers now have to prove that custom and third-party code — including the open source packages it depends on — is tested for vulnerabilities before release and monitored afterward. That shift has exposed a real gap in how many teams run AppSec: point-in-time SAST/DAST scans from vendors like Veracode satisfy an audit checkbox but miss the dependency, build-pipeline, and runtime context assessors increasingly ask for. This post breaks down what PCI DSS 4.0 actually requires, where traditional AppSec testing falls short, what it costs to get wrong, and what a compliant program looks like in practice.
What does PCI DSS actually require for application security?
PCI DSS 4.0 requires that all public-facing web applications and custom code be reviewed for common vulnerabilities before deployment and reviewed again after any significant change, per Requirements 6.2.3, 6.2.4, and 6.4.1/6.4.2. Requirement 6.2.3 mandates that custom software be reviewed — manually or via automated tools — to identify coding vulnerabilities prior to release, covering the OWASP Top 10 categories (injection, broken authentication, insecure deserialization, and so on). Requirement 6.2.4 goes further, requiring documented mitigation techniques for common attack classes at the design and coding stage, not just detection after the fact. Requirement 6.4.2, which became a mandatory best practice on March 31, 2025, requires an automated technical solution — a WAF or equivalent — that continually detects and prevents web-based attacks for public-facing applications, replacing the old option to do manual reviews every 12 months. On top of that, Requirement 11.3.1 requires internal and external vulnerability scans at least once every three months, and 11.4.1 requires penetration testing at least annually and after significant infrastructure or application changes. Together, these clauses turn AppSec testing from a nice-to-have into an audit line item with specific cadences, specific coverage requirements, and specific evidence retention rules (PCI DSS requires audit logs and scan history retained for at least 12 months, with 3 months immediately available).
Why did PCI DSS 4.0 raise the bar for AppSec testing?
PCI DSS 4.0 raised the bar because card-present fraud has migrated almost entirely to e-commerce and API attack surfaces, and the PCI Security Standards Council rewrote Requirement 6 to reflect that. Verizon's 2024 Data Breach Investigations Report found that web application attacks were involved in roughly 25% of breaches overall, and for the retail and hospitality sectors that overlap heavily with PCI scope, that share climbs higher. The Council's response was to move from "scan once a year and file the report" toward continuous testing: 6.3.2 now requires an accurate, up-to-date inventory of all bespoke and custom software along with third-party components used within it — effectively a software bill of materials (SBOM) requirement — because assessors kept finding that breaches traced back to unpatched or unknown open source dependencies, not just first-party code defects. This is also why PCI DSS 4.0 explicitly folds in supply chain risk: Requirement 6.3.2's component inventory exists precisely because a vulnerability in a transitive dependency is indistinguishable from a vulnerability in your own code once it's compiled into a running application.
Where do traditional AppSec tools like Veracode fall short for PCI DSS 4.0?
Traditional platforms like Veracode fall short because they were built around periodic static and dynamic scanning of application code, not continuous visibility into the software supply chain that Requirement 6.3.2 now demands. Veracode's SAST/DAST engines are effective at catching classic code-level flaws — the kind Requirement 6.2.3 asks about — but customers consistently report that its component/SCA coverage and scan turnaround (Veracode's static scans can take from several hours up to 24+ hours for large codebases, per its own documentation) slow down the release cadence PCI 4.0 now expects around every significant change. More importantly, a scanner-centric model treats the build pipeline, package registries, and CI/CD credentials as out of scope, even though a growing share of real-world breaches (the 2021 Codecov and 2022 CircleCI incidents are the canonical examples) originate in the pipeline rather than the application code itself. An assessor evaluating Requirement 6.3.2 and the related 6.4.3 (which requires all payment page scripts to be authorized, integrity-verified, and inventoried) needs evidence about where code came from and what touched it before it shipped — evidence a code scanner alone doesn't produce. Teams that rely solely on legacy AppSec suites often end up bolting on separate SBOM tooling, separate CI/CD security controls, and separate script-integrity monitoring just to close the gaps 4.0 introduced, which fragments evidence collection right when auditors want a single coherent trail.
How much does non-compliance actually cost?
Non-compliance is expensive both directly and indirectly: card brands can levy fines of $5,000 to $100,000 per month for non-compliance depending on merchant level and transaction volume, and that's before breach-related costs. IBM's Cost of a Data Breach Report 2024 put the global average cost of a data breach at $4.88 million, with breaches involving customer PII (which overlaps heavily with cardholder data environments) trending above that average. For payment-specific incidents, Mastercard and Visa can also impose non-compliance assessments retroactively if a breach occurs while a merchant was out of compliance, and acquiring banks frequently pass increased transaction fees or reserve requirements on to merchants after an incident. The compliance deadline itself has already created cost pressure: organizations that treated the March 31, 2025 enforcement date as a hard deadline and scrambled to add SBOM generation, script inventories, and automated WAF coverage in the final quarter typically paid a premium for expedited assessor time and rushed tooling procurement compared to teams that planned twelve months out.
What does a PCI-ready AppSec testing program actually look like?
A PCI-ready program combines four things running continuously, not four things run once a year: static analysis on every code change tied to Requirement 6.2.3/6.2.4, software composition analysis with a maintained SBOM to satisfy 6.3.2, an automated WAF or equivalent control for public-facing apps under 6.4.2, and quarterly vulnerability scans plus annual penetration testing under 11.3 and 11.4. Crucially, the evidence has to be reconstructable on demand: assessors performing a Report on Compliance (RoC) will ask for scan history, remediation timelines, and proof that a "high" or "critical" finding didn't ship to production, which is far easier when tooling produces a single, queryable trail rather than exports stitched together from three or four disconnected dashboards. Mature programs also track remediation SLAs internally — many map "critical" findings to a 15-day fix window and "high" findings to 30 days, mirroring the risk-ranking approach PCI DSS itself recommends in Requirement 6.3.1 — so that the quarterly scan cycle never surfaces a finding that's been sitting unaddressed for months.
How Safeguard Helps
Safeguard is built around the part of PCI DSS 4.0 that legacy AppSec vendors treat as an afterthought: the software supply chain. Instead of bolting SCA onto a code scanner, Safeguard starts from a continuously maintained software bill of materials for every application in scope, mapping directly to Requirement 6.3.2's component inventory mandate, and tracks provenance from source repository through build pipeline to deployed artifact — closing the exact evidence gap that trips up teams during a RoC when an assessor asks "where did this dependency come from and who approved it." Safeguard's pipeline-level monitoring extends coverage to CI/CD configuration and build credentials, addressing the class of supply chain attacks that a Veracode-style scan-only approach never sees, while its findings feed a single evidence trail — scan history, SBOM snapshots, remediation timestamps — designed to be handed directly to a Qualified Security Assessor rather than reconstructed manually across tools. For teams already running static or dynamic scanning elsewhere, Safeguard is designed to sit alongside those tools and close the 6.3.2, 6.4.3, and pipeline-integrity gaps rather than force a rip-and-replace, so a PCI DSS 4.0 assessment doesn't hinge on a single vendor's roadmap. The result is an AppSec testing program that maps cleanly to Requirement 6's clauses instead of approximating them, with remediation SLAs and audit-ready reporting built in rather than assembled under deadline pressure.