Yes, both are in play, but through different requirements. Requirement 6.2 secure development rules apply to bespoke and custom software and explicitly not to third-party software. Third-party components still matter through vulnerability management in 6.3, where they must be inventoried, ranked and patched. This is a plain-language guide, not legal advice.
Definitions that matter
Bespoke and custom software is software developed for or by the entity for the entity's own use. The SAQ D text for 6.2.1 says this "does not apply to third-party software."
Third-party software is anything you did not write: operating systems, databases, frameworks and the open source packages inside your application.
Which requirement reaches which code
| Requirement | Your own code | Third-party and libraries |
|---|---|---|
| 6.2.1 secure development lifecycle | Yes | No |
| 6.2.3 pre-release code review | Yes | No |
| 6.2.4 defences against common attacks | Yes | No |
| 6.3.1 find and rank vulnerabilities | Yes | Yes |
| 6.3.2 software inventory | Yes | Yes, components incorporated into your software |
| 6.3.3 install security patches | Yes | Yes |
Row 6.3.1 states that "Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered." Row 6.3.2 asks for an inventory of bespoke and custom software and third-party software components incorporated into it, kept to support vulnerability and patch management.
What this means for a dependency tree
Your application's packages are third-party components, so you need to know which ones you ship, watch industry sources for new vulnerabilities in them, rank what you find, and apply critical or high-risk patches within the timeframe in 6.3.3 (covered in our post on patch timing under PCI DSS).
You are not asked to code-review a library the way you review your own pull requests. But a vulnerable library in a payment application still shows up through 6.3.
Steps
- List your in-scope applications and their repositories.
- Generate a component list per application, including transitive dependencies.
- Record owner, version and where it is deployed.
- Subscribe to advisory sources and map them to the list.
- Rank findings using your documented method.
- Patch and record dates.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each component is listed.
Quick check
Do I have to code-review open source libraries under 6.2.3?
The SAQ D text limits 6.2.3 code review to bespoke and custom software. Libraries fall under vulnerability management in 6.3 instead.
Does a vendor SDK count as third-party software?
Generally yes, if you did not develop it. Treat it as a component in your 6.3.2 inventory and confirm edge cases with your assessor.
One factual note on Safeguard: its SBOM and dependency scanning builds a component inventory across repositories and flags known vulnerable versions. A free scan is available at gold.safeguard.sh/scan.
Sources
- PCI DSS v4.0 SAQ D for Merchants (PCI SSC, April 2022)
- Just Published: PCI DSS v4.0.1 (PCI SSC blog)
This guide quotes the v4.0 text. v4.0.1 added and deleted no requirements, but check exact wording in the current version.
Last reviewed: 19 October 2026.
