PCI DSS v4.0.1 dedicates an entire requirement — Requirement 6 — to building and maintaining secure applications, and as of March 31, 2025, several previously "future-dated" sub-requirements became mandatory for every organization that stores, processes, or transmits cardholder data. That means a Level 1 merchant or service provider undergoing a Report on Compliance (RoC) today is assessed against rules that didn't exist in PCI DSS v3.2.1: a mandatory software component inventory (6.3.2), a 30-day patch window for critical and high vulnerabilities (6.3.3), and explicit code-review and secure-coding controls (6.2.3, 6.2.4). Most AppSec teams still map these requirements to whatever SAST or SCA tool they already own, then discover during the audit that coverage, evidence, and patch timelines don't line up with what a QSA expects to see. This post walks through what Requirement 6 actually demands, with the specific clause numbers, deadlines, and evidence a QSA will ask for.
What does PCI DSS Requirement 6 actually require for application security?
Requirement 6 requires organizations to develop and maintain secure systems and software through secure coding practices, vulnerability management, and change control — it is the single largest requirement in PCI DSS v4.0.1, spanning 6.1 through 6.5 with 25 individual sub-requirements. The core obligations break down into four buckets: bespoke and custom software must be developed using documented secure coding standards that address the OWASP Top 10 or equivalent (6.2.1–6.2.4); known vulnerabilities in both custom and third-party code must be identified and ranked using an industry-recognized methodology such as CVSS (6.3.1); a current inventory of software and its components must exist to support that vulnerability identification (6.3.2); and public-facing web applications must be protected by either a web application firewall or reviewed via manual/automated methods at least annually and after significant changes (6.4.1–6.4.2). Every one of these applies whether the assessment is a full onsite audit or a Self-Assessment Questionnaire (SAQ D), and QSAs will ask for dated artifacts — not a policy document — as evidence for each sub-requirement.
What is PCI DSS 6.3.2 and why does it require a software component inventory?
PCI DSS 6.3.2 requires organizations to maintain an inventory of bespoke and custom software, plus any third-party software components incorporated into it, specifically so that known vulnerabilities in those components can be identified and tracked. In practice, this is PCI's version of an SBOM (Software Bill of Materials) mandate: the standard's guidance explicitly references maintaining a list of components "to facilitate vulnerability and patch management." An assessor testing this control will typically sample two or three in-scope applications and ask to see a generated inventory that lists direct and transitive open-source dependencies, their versions, and the date the inventory was last refreshed. A spreadsheet updated once a year at renewal time does not satisfy this — the inventory has to reflect what's actually deployed, which for a team shipping weekly means the SBOM needs to be regenerated on every build, not produced retroactively for the audit.
How quickly must critical vulnerabilities be patched under PCI DSS 6.3.3?
PCI DSS 6.3.3 requires critical and high-severity vulnerabilities (per the CVSS scoring used under 6.3.1, generally a CVSS v3 base score of 7.0 or above) in bespoke, custom, and third-party software to be patched or remediated within one month of the patch's release. Other, lower-severity vulnerabilities must be addressed per the organization's own documented risk-ranking timeline, but the 30-day clock for high/critical findings is fixed by the standard itself. This is a meaningfully tighter window than many teams' existing SLAs: a 2024 sample of vulnerability-management benchmarks found average enterprise remediation times for critical CVEs running 60–100+ days, well outside PCI's 30-day requirement. During an assessment, a QSA will pull a sample of critical/high findings from the last 12 months and check the delta between disclosure or patch-release date and the remediation date in the organization's ticketing or SCA tooling — if that gap regularly exceeds 30 days, it's a finding, not a discussion point.
Does PCI DSS require security code reviews before deployment?
Yes — PCI DSS 6.2.3 requires all bespoke and custom software to undergo a code review, manual or automated, before it is released into production or made available to customers, specifically to identify coding vulnerabilities. 6.2.3.1, if automated tools are used to satisfy this, requires that manual review still occur for any high-risk vulnerabilities the tool cannot cover. Alongside this, 6.2.4 requires organizations to address common software attack techniques — injection flaws, buffer overflows, insecure cryptographic storage, cross-site scripting, and similar OWASP-class issues — through secure coding training and technique-specific controls during both design and code review. For audit evidence, this means a reviewable trail per release: a linked SAST/code-review finding set, a reviewer or tool identity, and a resolution status showing vulnerabilities were fixed, formally risk-accepted, or determined to be false positives before the release shipped, not after.
Which vulnerability sources count as "industry-recognized" under PCI DSS 6.3.1?
PCI DSS 6.3.1 requires that vulnerabilities in bespoke, custom, and third-party software be identified using an industry-recognized source — the standard names CVSS explicitly and expects organizations to also draw on vendor advisories, the National Vulnerability Database (NVD), or an equivalent structured feed rather than internal, informal tracking. The requirement further specifies that new vulnerabilities be identified on an ongoing basis, which QSAs interpret as continuous scanning, not a quarterly or annual sweep. A common finding during assessments is an organization that runs SCA scans only at release-gate time, missing vulnerabilities disclosed in dependencies that haven't been touched in months — 6.3.1 doesn't distinguish between "we didn't rebuild that service" and "we didn't know," so idle, unscanned code in production is still an open finding if a CVE against one of its components has since been published.
What happens when a QSA finds an application security gap during a PCI audit?
When a QSA identifies a gap against Requirement 6, the organization is marked "In Place with Remediation" or "Not in Place" for that control, and the RoC cannot be signed as fully compliant until the gap is remediated or a formal compensating control is documented and approved. For most acquiring banks and payment brands, a Not-in-Place finding on Requirement 6 triggers a remediation deadline — commonly 90 days — before revalidation is required, and repeated failures can result in increased transaction fees, mandated forensic review after a breach, or in severe cases, loss of card-processing privileges. Because Requirement 6 evidence spans code review logs, SBOM history, and patch-timeline data across an entire assessment period (typically 12 months), gaps discovered at audit time are expensive to backfill retroactively — the evidence either exists with timestamps or it doesn't.
How Safeguard Helps
Safeguard maps directly onto Requirement 6's evidence demands instead of leaving teams to reconstruct it manually. SBOM generation and ingest give you the continuously updated component inventory 6.3.2 requires, refreshed on every build rather than once a year. Reachability analysis distinguishes vulnerable dependencies that are actually exploitable in your running code from ones that are dead weight, so the 30-day clock in 6.3.3 gets spent on the findings that matter to a QSA and an attacker alike. Griffin AI triages new CVEs against your live inventory the moment they're published, satisfying 6.3.1's "ongoing identification" bar instead of waiting for the next scheduled scan. And auto-fix PRs close the loop on 6.2.3 and 6.3.3 by shipping the remediation — with a reviewable, timestamped trail — before the patch-release clock runs out.