Reviewed before release, or found after.
PCI DSS v4.0.1 Requirement 6.2.3 covers bespoke and custom software: the code you write yourselves, or that is written for you, that runs in or touches the cardholder data environment. Before that code is released to production or to customers, it is reviewed to find and correct potential coding vulnerabilities. The review checks the code against secure coding guidelines, looks for existing and emerging vulnerabilities, and the corrections are made before release, not scheduled after it.
The requirement allows the review to be manual or automated. Manual review has its own sub-requirement, 6.2.3.1, with conditions on who reviews and who approves. This page is about the automated path and the pull request, where the review naturally sits.
The shapes the same control failure takes.
A 6.2.3 miss is a coding vulnerability in bespoke payment code that reached release without being found. In a diff, the recurring shapes:
A payment webhook trusts its payload
The signature check on a callback from the payment provider is removed or bypassed, so anyone who can reach the endpoint can mark an order paid.
The amount comes from the client
A checkout or refund path takes the price, currency or refund amount from the request body instead of recomputing it on the server from the order.
Card data reaches a log or an error
A debug line, an exception message or a request dump writes the primary account number or authentication data somewhere it was never meant to be stored.
An access check is missing on a payment action
A refund, payout or card-on-file endpoint checks that the caller is signed in but not that the order or card belongs to them.
Input reaches a query or a template unescaped
A search, reporting or admin feature in the payment application builds a query or page from user input, opening an injection path next to cardholder data.
A payment webhook that stops verifying the signature.
Local testing of the payment callback is painful because every event must be signed. A change swaps the verified parse for a plain JSON parse "for now". The handler still marks orders paid on a success event, and the endpoint is public, so a forged request with any order id now does the same.
export async function handleWebhook(rawBody: string, signature: string) {- const event = provider.webhooks.verify(rawBody, signature, WEBHOOK_SECRET);+ const event = JSON.parse(rawBody); // TODO restore verify after local testing if (event.type === "payment.succeeded") { await orders.markPaid(event.data.orderId); }This removes signature verification from the payment webhook. The handler still marks an order paid on a success event, and nothing now proves the event came from the payment provider, so a forged request can mark any order paid. That is a coding vulnerability in bespoke payment software, and 6.2.3 expects it to be found and corrected before release. Restore the verified parse, and for local testing sign test events with a test secret instead of skipping the check.
Security reading of the same pull request
heygrc reviews this pull request against 6.2.3. Aevral, an AI security reviewer from the same company, reads the same diff for coding vulnerabilities and posts them on the pull request as leads with evidence, before the change is released.
What that supports for 6.2.3: automated review before release, which the requirement allows. Correcting what it finds before release, and the change-control records, stay with you. Aevral posts at most two findings per review, so a large change can hold more issues than one review reports.
The assessor looks for the review, and for the fix before release.
A QSA assessing 6.2.3 examines your documented review procedures, interviews the people who run them, and examines evidence for changes to bespoke software: that each was reviewed before release and that what the review found was corrected before release, not merely logged. A review comment on a pull request is only half of that evidence; the other half is the commit that fixed it and the release that shipped after the fix. A webhook that went out without its signature check, with a TODO to restore it, is exactly the gap that sample is built to find.
A review, not your release decision.
heygrc flags changes to payment code that open a coding vulnerability and cites the requirement so the fix happens in the pull request. It does not decide what is in scope for PCI DSS, hold your change-control records, or approve a release. Neither heygrc nor Aevral is the manual code review described in 6.2.3.1.