heygrc
PCI DSS in code

PCI DSS, reviewed in the pull request.

PCI DSS is one of the more concrete frameworks about what code must do. It is prescriptive on exactly the things a pull request can change: whether a card number ever lands unprotected, whether transmission is encrypted, whether access to the cardholder data environment is restricted and authenticated. Those requirements turn on what the code does, which a pull request changes.

The cardholder data environment is a code boundary

Scope creep is a pull request, not a memo.

The expensive surprises in PCI assessments are usually scope: a system that started handling card data when nobody updated the diagram, a log that quietly captured a PAN, a new service that reached into the cardholder data environment. Each of those expansions happens in code, one merge at a time, and is invisible until an assessor finds it. heygrc reads the change against the requirement it touches and names it, so the boundary stays where you think it is.

Requirements that surface in a diff

The PCI DSS requirements a review can actually catch.

Each row is a real requirement reference and the kind of change that trips it. heygrc cites the requirement on the finding, not a vague cardholder-data note.

  • Req 3protect stored account data

    A primary account number (PAN) or other account data is logged, cached, or stored in a new place without being rendered unreadable, or a masking step is removed.

  • Req 4encrypt transmission over open networks

    A TLS floor drops, certificate verification is disabled, or cardholder data starts crossing a public network on a channel that is no longer strongly encrypted.

  • Req 6develop and maintain secure software

    A secure-coding control is bypassed (a query built by string concatenation, output rendered unescaped), or a known-vulnerability check is disabled to pass a change.

  • Req 7restrict access by need to know

    A role broadens or an authorization check is dropped so a component reaches cardholder data it does not need for its function.

  • Req 8authenticate access

    A multi-factor check is skipped on a path into the cardholder data environment, a password rule is relaxed, or a shared or default credential is introduced.

  • Req 10log and monitor access

    A change removes or narrows the audit logging of access to account data or to the systems that handle it, shrinking the trail Req 10 expects.

Worked example

A log line that breaks Req 3.

A pull request adds a log to debug a failed payment. It logs the full card object, which includes the primary account number in the clear, into a log store that was never in scope to hold it.

payments/charge.ts+1 −0
async function charge(card: Card, amount: number) {
+  logger.warn("charge failed", { card, amount })  return gateway.charge(card, amount)
}
heygrcPCI DSS Req 3

This logs the full card object, including the PAN, into application logs. Req 3 (protect stored account data) expects the PAN to be rendered unreadable wherever it is stored, and writing it to logs in the clear both violates that and pulls the log store into PCI scope. Log a transaction id and the gateway error, never the card.

What this is, and is not

A review, not a QSA.

heygrc flags changes that touch a PCI DSS requirement and cites the requirement so the fix happens in the pull request. It does not perform your assessment, complete your Self-Assessment Questionnaire, or act as a Qualified Security Assessor. It catches the change early so a cardholder-data requirement holds in code review instead of becoming an assessment finding. heygrc is in early access.