Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›PCI DSS 4.0 Software Security
PCI SSC · PCI DSS v4.0.1

PCI DSS 4.0 software security compliance

how to meet Requirements 6 and 11 for secure development, vulnerability management, and payment-page protection

PCI DSS v4.0 reshaped how entities that store, process, or transmit cardholder data build and test software. The future-dated requirements that were optional during the transition became mandatory on 31 March 2025, including a component inventory (Req 6.3.2), payment-page script management (Req 6.4.3), and client-side tamper detection (Req 11.6.1).

This page explains how to meet the software security half of the standard: secure SDLC and vulnerability ranking under Requirement 6, and scanning, penetration testing, and change-detection under Requirement 11. It cites the specific requirement numbers and links the official PCI SSC document library.

Talk to our advisory team Read it in the PCI SSC Document Library
At a glance
31 Mar 2025Future-dated requirements became mandatory
v4.0.1Current revision (June 2024)
QuarterlyInternal and external ASV vulnerability scans
AnnualInternal and external penetration testing
Payment Card Industry Data Security Standard (PCI DSS) v4.0.1
Why it matters

The transition period is over. Software security is now assessed, not aspirational.

PCI DSS v4.0 was published in March 2022, and v4.0.1 followed in June 2024 with clarifications. The standard applies to any merchant, processor, or service provider that stores, processes, or transmits cardholder data. It is global in reach but heavily enforced across US financial services, where acquirers and card brands tie attestation directly to the right to process payments.

Many of the new software security controls were marked future-dated, meaning assessors only flagged them as best practice through the transition. That window closed on 31 March 2025. From that date, controls like the component inventory (Req 6.3.2), authorised payment-page scripts (Req 6.4.3), and client-side tamper detection (Req 11.6.1) are in scope for full assessment.

The practical effect is that appsec evidence is no longer optional. A Report on Compliance now expects a ranked vulnerability process (Req 6.3.1), a maintained inventory of bespoke and third-party components (Req 6.3.2), quarterly scans (Req 11.3), and annual penetration testing (Req 11.4) with current artefacts you can show on demand.

How O3 helps

Find it before attackers do. Catch it if they try. Fix it fast.

Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.

1 · Find it first

Test like an AI-assisted attacker

An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.

2 · Catch it live

Detect and block exploitation at runtime

A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.

3 · Fix it fast

Auto-patch what is reachable

Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Remediation expectations

The clock by finding type

Indicative fix windows. Tightest where exposure and active exploitation meet.

Internal & external vulnerability scans (Req 11.3)Quarterly + after significant change
Penetration testing (Req 11.4)At least annually + after significant change
Critical/high vulnerability remediation (Req 6.3.1 / 11.3)Per risk ranking, criticals promptly
Payment-page script & tamper review (Req 6.4.3 / 11.6.1)At least weekly check-in interval
Requirement 6.2

How to build a secure SDLC for bespoke and custom software

Requirement 6.2 expects bespoke and custom software to be developed securely, based on industry standards and secure coding guidelines, with software-attack techniques addressed in design and code.

PCI DSS v4.0.1 Req 6.2Req 6.2.2Req 6.2.3Req 6.2.4
Document a secure SDLC that covers requirements, design, coding, and testing, and map each phase to PCI DSS 6.2 sub-requirements.
Train developers at least annually on secure coding for the languages and frameworks in use, as required by 6.2.2.
Review bespoke and custom code before release, using manual review or automated tools, per 6.2.3, and fix issues before deployment.
Address common software-attack techniques such as injection, insecure deserialization, and broken access control under 6.2.4.
Where O3 helps

O3 runs code-property-graph SAST with interprocedural source-to-sink taint analysis and secret scanning, giving the automated code review evidence 6.2.3 and 6.2.4 expect before release.

Requirement 6.3.1

How to identify and rank security vulnerabilities

Requirement 6.3.1 requires a process to identify security vulnerabilities using reputable external sources and to assign a risk ranking to each one so remediation can be prioritised.

PCI DSS v4.0.1 Req 6.3.1
Subscribe to authoritative vulnerability sources such as CVE, vendor advisories, and the CISA KEV catalog, as 6.3.1 expects.
Assign a risk ranking to every vulnerability, with at least a high/critical tier defined, and document the criteria.
Feed exploit-likelihood signals such as EPSS and known-exploited status into ranking so remediation effort targets real risk.
Route ranked findings into a tracked remediation workflow with owners and due dates aligned to the ranking.
Where O3 helps

O3 prioritises findings with EPSS plus CISA KEV and uses function-level reachability to confirm whether a vulnerable path is actually reachable, sharpening the 6.3.1 risk ranking instead of drowning teams in raw CVE counts.

Requirement 6.3.2

How to maintain an inventory of bespoke and third-party software components

Requirement 6.3.2 requires a maintained inventory of bespoke and custom software plus third-party software components, so vulnerabilities in those components can be managed. This is the SBOM-adjacent control most teams find new in v4.0.

PCI DSS v4.0.1 Req 6.3.2Req 6.3.3
Generate a component inventory for every bespoke and custom application, listing third-party and open-source libraries and their versions.
Adopt a machine-readable format such as CycloneDX or SPDX so the inventory can be diffed, queried, and kept current automatically.
Refresh the inventory on every build so it reflects what is actually deployed, not a point-in-time snapshot.
Link each component to its known vulnerabilities so 6.3.1 ranking and 6.3.3 patching can act on the inventory.
Where O3 helps

O3 produces a CycloneDX SBOM enriched with deps.dev and VEX data, runs SCA against OSV, and flags malicious dependencies such as typosquats and compromised maintainers, directly satisfying the 6.3.2 inventory-to-vulnerability link.

Requirement 6.4.3

How to manage and authorize payment-page scripts

Requirement 6.4.3 requires that all scripts loaded and executed in the consumer browser on payment pages are managed: each is authorized, its integrity is assured, and an up-to-date inventory with justification is maintained.

PCI DSS v4.0.1 Req 6.4.3
Build an inventory of every script that executes on payment pages, including third-party tags, analytics, and chat widgets, per 6.4.3.
Require explicit authorization before any script is added, with a documented business justification for each entry.
Assure script integrity using Subresource Integrity hashes or a content security policy that pins allowed sources.
Review the script inventory regularly and remove anything no longer authorized or justified.
Where O3 helps

O3 L7 deep packet inspection with egress baselining can surface unexpected outbound calls and data exfiltration from client-side script behaviour, supporting the monitoring side of 6.4.3 alongside browser-level integrity controls.

Requirement 11.3

How to run quarterly internal and external vulnerability scans

Requirement 11.3 requires internal and external vulnerability scans at least quarterly and after any significant change, with external scans performed by a PCI Approved Scanning Vendor (ASV).

PCI DSS v4.0.1 Req 11.3Req 11.3.1Req 11.3.2
Run authenticated internal scans at least quarterly and after significant changes, and resolve high-risk findings per 11.3.1.
Engage a PCI SSC Approved Scanning Vendor for external scans quarterly until a passing scan is achieved, per 11.3.2.
Define what counts as a significant change so post-change scans are triggered consistently.
Retain scan reports and remediation evidence to demonstrate the quarterly cadence to your assessor.
Where O3 helps

O3 continuous SAST, SCA, and reachability scanning gives the internal change-driven vulnerability evidence that complements the ASV external scan required by 11.3.2.

Requirement 11.4

How to scope and run penetration testing

Requirement 11.4 requires a defined penetration testing methodology with internal and external tests at least annually and after significant changes, covering both the network layer and the application layer.

PCI DSS v4.0.1 Req 11.4Req 11.4.1Req 11.4.3Req 11.4.4
Document a pentest methodology based on an industry-accepted approach, as 11.4.1 requires.
Perform external and internal penetration tests at least annually and after significant infrastructure or application changes, per 11.4.3 and 11.4.4.
Test segmentation controls so the cardholder data environment is properly isolated, per 11.4.5 and 11.4.6 for service providers.
Remediate exploitable findings and re-test to confirm the fixes hold.
Where O3 helps

O3 agentic DAST and pentest covers 50-plus vulnerability classes, adding automated, repeatable application-layer testing between annual engagements to support the 11.4 methodology and significant-change re-tests.

Requirement 11.6.1

How to detect tampering on payment pages

Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of the HTTP headers and content of payment pages as received by the consumer browser.

PCI DSS v4.0.1 Req 11.6.1
Deploy a mechanism that evaluates the HTTP headers and script content delivered to the browser on payment pages, per 11.6.1.
Configure it to alert on unauthorized changes and run the comparison at least weekly, or on a frequency set by a targeted risk analysis.
Tie alerts into incident response so a flagged change is investigated promptly.
Keep records of detections and reviews to evidence the control to your assessor.
Where O3 helps

O3 L7 deep packet inspection with egress baselining and DNS-tunnel detection can flag anomalous outbound behaviour from compromised payment-page scripts, complementing the header and content tamper-detection 11.6.1 requires.

The whole framework

Every software security control, mapped to how you meet it

All 16 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.

9Requirement 6
Develop and maintain secure systems and software
2Requirement 11.3
Vulnerability scanning
4Requirement 11.4
Penetration testing
1Requirement 11.6
Payment-page change detection
Requirement area
Secure SDLC for bespoke/custom softwareReq 6.2Document phases against secure coding standards
Annual secure-coding developer trainingReq 6.2.2Train on in-use languages and frameworks
Pre-release code reviewReq 6.2.3Manual or automated review before deploy
Protect against software-attack techniquesReq 6.2.4Address injection, deserialization, access control
Identify and rank vulnerabilitiesReq 6.3.1Use reputable sources, assign risk ranking
Inventory of bespoke + third-party componentsReq 6.3.2Maintain machine-readable component inventory
Patch known vulnerabilitiesReq 6.3.3Install applicable security patches by risk
Change and tamper controls for codeReq 6.4Review public-facing app changes pre-release
Manage and authorize payment-page scriptsReq 6.4.3Authorize, integrity-check, inventory each script
Internal vulnerability scansReq 11.3.1Quarterly and after significant change
External ASV vulnerability scansReq 11.3.2Quarterly via Approved Scanning Vendor
Penetration testing methodologyReq 11.4.1Define industry-accepted test approach
External penetration testingReq 11.4.3At least annually and after major change
Internal penetration testingReq 11.4.4At least annually and after major change
Segmentation penetration testingReq 11.4.5 / 11.4.6Verify CDE isolation, more often for providers
Payment-page tamper/change detectionReq 11.6.1Alert on header and content modification

Turn Requirements 6 and 11 into evidence you can show

O3 Security covers the appsec spine of PCI DSS 4.0: SAST and secret scanning for secure development, SCA with a CycloneDX SBOM for the 6.3.2 component inventory, EPSS and KEV prioritisation with reachability for 6.3.1 ranking, agentic DAST for 11.4 testing, and L7 egress monitoring to support payment-page controls. See how it maps to your Report on Compliance.

Read it in the PCI SSC Document Library
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • The future-dated requirements introduced in PCI DSS v4.0, including the component inventory (Req 6.3.2), payment-page script management (Req 6.4.3), and client-side tamper detection (Req 11.6.1), became mandatory on 31 March 2025. Before that date assessors treated them as best practice during the transition. v4.0.1 (June 2024) is the current revision.
  • PCI DSS does not use the term SBOM, but Requirement 6.3.2 requires a maintained inventory of bespoke and custom software plus third-party components so vulnerabilities can be managed. A machine-readable SBOM in CycloneDX or SPDX is the practical way to satisfy 6.3.2 and feed the 6.3.1 ranking and 6.3.3 patching processes.
  • Requirement 6.4.3 requires that every script loaded and executed in the consumer browser on a payment page is authorized, has its integrity assured, and appears in an up-to-date inventory with a written justification. Teams typically use Subresource Integrity hashes or a content security policy plus a reviewed script inventory.
  • Requirement 6.4.3 is about authorizing and controlling which scripts run on payment pages. Requirement 11.6.1 is the detective control: a tamper- and change-detection mechanism that alerts personnel when the HTTP headers or content of a payment page are modified as received by the browser, checked at least weekly or per a targeted risk analysis.
  • Requirement 11.3 requires internal and external vulnerability scans at least quarterly and after significant changes, with external scans run by a PCI Approved Scanning Vendor. Requirement 11.4 requires internal and external penetration testing at least annually and after significant infrastructure or application changes, covering network and application layers.
  • Requirement 6.3.1 is the process to identify security vulnerabilities from reputable sources and assign each a risk ranking. Requirement 6.3.2 is the underlying inventory of bespoke, custom, and third-party components that the 6.3.1 process acts on. Together they let you find, rank, and patch (6.3.3) vulnerabilities in what you actually ship.
  • Any entity that stores, processes, or transmits cardholder data, including merchants, payment processors, and service providers. PCI DSS is maintained by the PCI Security Standards Council and is global, though it is heavily enforced across US financial services where card brands and acquirers tie compliance to the ability to process payments.
  • Yes. Requirement 6.2.3 allows bespoke and custom code to be reviewed manually or with automated code review tools before release, provided issues are corrected first. Code-property-graph SAST with interprocedural taint analysis can provide that automated review and produce the artefacts an assessor expects, alongside developer review for context.

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.