feat: add two robust PostHog PII rules

[joethreepwood]

Summary

Hardens PII detection beyond the single posthog_pii_in_capture_call rule. Sarah flagged it could be more robust — these fill the two biggest gaps: more call-sites and value-shaped detection.

posthog_pii_in_person_properties

Sensitive PII passed to person-property call-sites: register, register_once, setPersonProperties, setPersonPropertiesForFlags. Mirrors the identify() half of the existing rule — email and names are standard, expected person properties (NOT flagged); only regulated PII is (SSN, DOB, financial, government ID, medical).

posthog_pii_value_in_tracking_call

PII-shaped literal values, regardless of key name — catches PII hidden under innocuous keys like posthog.capture('signup', { referrer: 'jane@example.com' }), which the key-name rule misses. Matches:

• email literal — capture() only (an email value in identify()/person-properties is the standard, correct pattern)
• US SSN (123-45-6789) in any tracking call
• separator-grouped card number (4111 1111 1111 1111) in any tracking call

Conventions followed

• One rule per file, filename === rule name; all six meta fields (description, remediation, severity, category, action, scan_context)
• category = posthog_pii, severity = high, action = remediate, scan_context = output (matches the existing PII rule)
• No regex lookarounds (YARA-X rejects them); same first-{}-object FP-avoidance scoping as the sibling rule
• Deliberate precision over recall to limit false positives: card detection requires separators (YARA-X can't run a Luhn check, so an unseparated 16-digit run is intentionally not matched)

Test plan

• 19 new tests (positive / negative / metadata per rule) under __tests__/rules/
• pnpm test — full suite green (535 tests, 32 files)
• Negative coverage locks in the FP guards: email-in-identify, name in person properties, unseparated 16-digit runs, and capture-owned PII not double-firing the person-property rule

Note

Independent of the in-flight roin-orca-rules branch (it doesn't touch PII rules). The PostHog wizard ships an inline mirror of these patterns (PostHog/wizard#510) until it consumes warlock directly.

🤖 Generated with Claude Code

[sarahxsanders]

one missing test then you're a warlock harry >:)

[sarahxsanders]

tiny nit. this rule only catches emails written as literal strings, not when passed as a variable. it's fine as a limit if that's intended, but might be worth adding a comment here for context:

// Known limit: only catches quoted email values, not variables

triage will catch most of this at runtime but it could potentially be a gap and having the context for robots and humans is helpful!

[joethreepwood]

Added in 7ffc998 — a 'Known limit' note in the rule header: only catches quoted/literal values, not variables (e.g. { email: userEmail }); runtime triage covers most of those, this rule is the static-analysis backstop for hardcoded leaks.

[sarahxsanders]

rule 1 has a test that confirms it correctly doesn't fire on { $set: { ssn: '...' } }

rule 2 behaves the same way but there's no test for it. could we add a matching negative test? something like

it('does NOT match an SSN value nested inside a $set object', async () => {
  await expectRuleDidNotMatch(
    `posthog.setPersonProperties({ $set: { ssn: '123-45-6789' } })`,
    RULE,
  );
});

[joethreepwood]

Added your suggested test verbatim in 7ffc998 — confirms the value rule stays silent on setPersonProperties({ $set: { ssn: '123-45-6789' } }). The nested object isn't matched because the [^{}]* scope stops at the inner brace, same FP-avoidance as rule 1. Suite green (536).

[joethreepwood]

Update: the wizard-side inline mirror referenced in the PR description was dropped (PostHog/wizard#510) at review — the wizard will consume these rules through the warlock→wizard scanner wiring instead of a hand-maintained copy. These two rules remain the source of truth here.

[joethreepwood]

Thanks @sarahxsanders — both addressed in 7ffc998:

• Literal-only limit documented — added a // Known limit: note to posthog_pii_value_in_tracking_call: it only catches quoted/literal values, not variables (e.g. { email: userEmail }); runtime triage covers most of those, this rule is the static-analysis backstop for hardcoded leaks.
• Nested $set negative test — added your suggested test verbatim; confirms the value rule stays silent on setPersonProperties({ $set: { ssn: '…' } }), matching the coverage the person-properties rule already had.

Full suite green (536). Heads up: the wizard-side inline mirror these rules referenced was dropped at review (PostHog/wizard#510) — the wizard will consume them through the warlock→wizard wiring instead.