PCI DSS 4.0 is the version of the standard most assessors are now writing reports against, with the future-dated requirements coming fully into force through 2025 and into 2026. For software teams that build or operate cardholder data environments, the changes in Requirement 6 and Requirement 12.8 are the ones that demand the most new evidence, because they pull supply chain risk into the audit scope in ways the previous version only hinted at.
The framework's intent is straightforward. If a payment-handling application depends on third-party software, and that third-party software introduces vulnerabilities or weaknesses, the merchant or service provider remains responsible for the cardholder data passing through the system. PCI DSS 4.0 codifies that responsibility into specific controls, and each control demands evidence that the controls operated as designed.
The supply chain reach of Requirement 6
Requirement 6 covers secure systems and software. The 4.0 revision expands its reach in three directions that matter for supply chain evidence.
Requirement 6.3 addresses security vulnerabilities in software, both bespoke and third-party. The control demands that vulnerabilities be identified through trustworthy sources, classified by severity, and remediated within timeframes proportional to the risk. For third-party components, this means continuous awareness of advisories affecting the dependencies in scope, not a once-a-quarter scan.
Requirement 6.3.2 specifically calls out an inventory of bespoke and custom software, including third-party components incorporated into custom software. This is an SBOM, in everything but name. The assessor expects to see a current list, kept up to date as the software evolves, with enough detail to support vulnerability management.
Requirement 6.4 covers public-facing web applications. The control requires methods that detect and prevent web-based attacks, with explicit attention to vulnerabilities in third-party libraries that contribute to the attack surface.
Requirement 12.8 and supplier oversight
Requirement 12.8 governs the management of third-party service providers. The 4.0 revision expects organizations to maintain a documented list of providers, monitor their PCI DSS compliance status, and define responsibilities clearly. For software supply chains, the practical effect is that vendors providing critical components or services need ongoing oversight, and the oversight needs to be demonstrable.
The control does not require that every open-source dependency be treated as a service provider. It does require that the organization understand which third parties have access to or impact on cardholder data systems, and that the relationships are governed accordingly. SBOM-driven inventory makes this distinction tractable, because it gives the team a basis for identifying which dependencies are in scope and which are not.
The evidence flow that satisfies the controls
A working evidence flow for PCI DSS 4.0 software security has five connected stages.
The first stage is build-time SBOM generation. Every release of a payment-handling application produces an SBOM that captures the components in scope. The SBOM is signed, timestamped, and stored against the release. This artifact is the foundation for Requirement 6.3.2 and the supplier-side reach of 12.8.
The second stage is continuous vulnerability monitoring against the SBOM. As advisories are published, findings are tied to the affected components in the affected SBOM versions. This satisfies the trustworthy-source and classification expectations of Requirement 6.3.1.
The third stage is risk-based triage. Each finding is assessed for exploitability in the actual context of the application. A high-severity vulnerability in a code path that is not reachable in the deployed configuration may be deprioritized, but the assessment must be documented. The triage record is the evidence that the classification was applied, not just received.
The fourth stage is remediation tracking. When a fix is applied, the action is logged against the original finding, with the timeframe captured. PCI DSS 4.0 expects critical vulnerabilities to be addressed within a month, and the timeline evidence has to be specific enough to demonstrate compliance with the policy the organization defined.
The fifth stage is supplier oversight, which draws on the inventory and the risk records to maintain the 12.8 list. Critical components and services are tracked, their compliance posture is documented, and the relationships are reviewed on a defined cadence.
How Safeguard supports the flow
Safeguard sits at the points where these artifacts are produced. When a repository is connected, SBOMs are generated on every build and retained against the release identifier. When a vulnerability is detected, the finding is recorded with the affected component, the affected SBOM version, the severity, and the exploitability signal. When a triage decision is made, the rationale, the user, and the linked artifacts are captured. When a fix is shipped, the new SBOM links back to the finding and closes the loop.
Policy gates enforce the timeframes the organization defines. A gate can block release if a critical vulnerability has been open longer than the PCI DSS policy allows, with the evaluation logged either way. The gate becomes both a control and an evidence source.
For Requirement 12.8, the inventory of in-scope components and services is derived from the SBOM data, with critical entries flagged for ongoing tracking. Supplier risk assessments capture the compliance posture of external providers and the relationships are reviewed against the organization's defined cadence.
What the assessor will look for
A PCI DSS 4.0 assessor walking through the software security controls is testing two things. The first is design: are the controls written down, are the policies clear, do they map to the requirements. The second is operation: did the controls actually function during the period under review, on the population they were supposed to cover.
For supply chain evidence, the operation question is the harder one. The assessor will sample releases. For each sampled release, they will expect an SBOM, the findings present at the time, the triage decisions, and the remediation records. If any of those artifacts cannot be produced for any sampled release, the control has a gap, and the gap will land in the report.
Continuous evidence generation defends against this risk by ensuring the artifacts exist for every release, not just the ones the team remembered to capture. The assessor's sample is uniform, because the population is uniform.
The 90-day cadence of authenticated scanning
PCI DSS 4.0 introduces stricter expectations around authenticated internal scanning, with quarterly cadences and remediation timelines tied to severity. While this is primarily an infrastructure control, the software supply chain feeds into it directly. Vulnerabilities discovered through authenticated scanning often originate in third-party components, and the response requires the same SBOM-anchored evidence the application-layer controls produce.
Treating the supply chain evidence as a shared substrate across Requirement 6, Requirement 11, and Requirement 12.8 reduces duplication and produces a consistent narrative for the assessor.
Preparing the evidence pack
A clean PCI DSS 4.0 software security evidence pack covers the full release population for the assessment period. For each in-scope application, the pack includes the SBOMs, the findings, the triage decisions, the remediation records, the gate evaluations, and the supplier oversight artifacts. The pack is structured against the requirements, with cross-references to the underlying records.
When the assessor arrives, the pack is the starting point, not the conclusion. The conversations that follow are about interpretation and exception handling, not reconstruction. That is the difference a continuous evidence flow makes, and PCI DSS 4.0 is one of the most direct cases for building it.