Why this matters
Test data leaks propagate widely and are often copied to non-PCI systems.
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)
Test data leaks propagate widely and are often copied to non-PCI systems.
Side-by-side examples engineers can pattern-match during review.
{ "card": { "pan": "4111111111111111", "cvv": "123" } }{ "card": { "pan_token": "tok_1PQ...". "last4": "1111" } }"pan": "4242424242424242""pan_token": "tok_abc123"From the same buckets as this rule.
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.
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)