PCI DSS 6.2.3: Bespoke and custom software is reviewed prior to being released into production
PCI DSS v4.0.1 control 6.2.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.2.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.2
Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:
- Code reviews ensure code is developed according to secure coding guidelines.
- Code reviews look for both existing and emerging software vulnerabilities.
- Appropriate corrections are implemented prior to release.
Summary
Review your own code before it ships, against your secure coding guidelines and for known and emerging vulnerabilities, and fix what you find before release rather than after.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 6.2.3.a | Examine documented software development procedures and interview responsible personnel to verify that processes are defined that require all bespoke and custom software to be reviewed in accordance with all elements specified in this requirement. |
| 6.2.3.b | Examine evidence of changes to bespoke and custom software to verify that the code changes were reviewed in accordance with all elements specified in this requirement. |
Procedure 6.2.3.b examines evidence of changes to bespoke and custom software, which means this control is tested against your actual commits and not against your policy. That is what separates it from 6.2.1, where a documented process is enough. Two elements are commonly half-met. "Look for both existing and emerging software vulnerabilities" is why a scanner pinned to an old ruleset is a weak answer. And "appropriate corrections are implemented prior to release" means the fix ships before the code does, so a review that files a ticket for later satisfies the first two bullets and fails the third.
What to prepare
- The secure coding guidelines the review is conducted against.
- A sample of recent changes with their review records, showing reviewer, findings and resolution.
- The tooling configuration, including when its rules were last updated.
- For anything released with a known finding, the record showing it was assessed and why it was acceptable.
How to implement it
1. Make the pull request the evidence. An approval on a merge request, with the comments attached, is the cheapest and most convincing artefact for 6.2.3.b, because it is generated by the work rather than for the assessment.
2. Give reviewers something to review against. "Looks fine" is not a review against secure coding guidelines. A short checklist tied to the guidelines turns the second bullet into something a reviewer can actually do.
3. Keep the tooling current, and say who updates it. The emerging half of the second bullet is about the rules being fresh, not about having a tool.
4. Block the release on the fix, not on the finding. If a finding can be deferred, the deferral needs a documented decision, otherwise the third bullet is not met.
Where this commonly fails
- Automated scanning treated as the whole review, so nothing checks the code against your own guidelines.
- Reviews evidenced for the release branch and skipped for hotfixes, which are the changes most likely to go out unreviewed.
- Findings raised as backlog tickets and the code released anyway, failing the "prior to release" element.
- The author approving their own change, which is visible in the very evidence the procedure examines.
Related controls
Others in section 6.2:
| Control | What it requires |
|---|---|
| 6.2.1 | Bespoke and custom software are developed securely… |
| 6.2.2 | Software development personnel working on bespoke and custom software are trained at least once… |
| 6.2.3.1 | If manual code reviews are performed for bespoke and custom software prior to release… |
| 6.2.4 | Software engineering techniques or other methods are defined and in use by software development… |
← 6.2.2 · All controls · 6.2.3.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.