Why this matters
Logs are broadly accessible; leaking CHD/SAD violates PCI DSS and creates high breach risk.
Never emit Primary Account Number (PAN) or Sensitive Authentication Data (SAD: CVV/CVC, full track data, PIN) to application or audit logs. Per PCI DSS 4.0 Req. 3 and 10, always mask PAN as first6last4 and fully redact SAD before logging.
Logs are broadly accessible; leaking CHD/SAD violates PCI DSS and creates high breach risk.
Side-by-side examples engineers can pattern-match during review.
logger.info("charge_created", { pan: "4111111111111111", cvv: "123" });const masked = maskPan("4111111111111111");
logger.info("charge_created", { pan: masked, cvv: "REDACTED" });
function maskPan(p){ return p.slice(0,6) + "*****" + p.slice(-4); }logger.debug(PAN=${pan})logger.debug(PAN=${maskPan(pan)})From the same buckets as this rule.
Reject PRs adding real PAN/CVV in fixtures, seeds, or mocks. Only use Luhn-valid test PANs from the gateway or opaque tokens (e.g., tok_) and never include CVV. Add a check to fail if a PAN regex is matched. (PCI DSS data minimization)
On every create/read/update/delete of CHD or tokens, write a structured audit event (who, what, when, result) without full PAN, including only pan_last4. Persist to an append-only/immutable sink. (PCI DSS 4.0 Req. 10)