Skip to main content

vulkro-sf masking-rules

Generates and validates the masking rules that protect sensitive data when production is copied into a sandbox. A sandbox seeded from production with real customer data is a compliance and breach exposure in waiting: every developer with sandbox access can read it. masking-rules derives a masking ruleset from the field-level PII classification Vulkro already computes for your metadata, so the rules stay in step with the schema instead of being hand-maintained and going stale.

Runs over the local project. No org connection is required to generate or validate rules.

Synopsis​

vulkro-sf masking-rules [PATH] [flags]

PATH defaults to the current directory and should contain an SFDX project or a retrieved metadata folder.

Flags​

FlagTypeDefaultDescription
--mode <mode>enumgenerategenerate derives a masking ruleset from the detected PII classification; validate checks an existing ruleset against the current schema and reports fields that are sensitive but unmasked.
--rules <path>string(none)The existing masking ruleset to check, required when --mode validate.
--format <fmt>enumyamlOutput format: yaml (a masking ruleset you can commit and feed to your seeding tool), json (the same ruleset for tools that prefer JSON), or table (a human-readable summary, most useful in validate mode).

Exit codes​

  • 0 - generation succeeded, or validation found no unmasked sensitive field.
  • 1 - in validate mode, one or more sensitive fields were found unmasked in the supplied ruleset.
  • 2 - error: bad arguments, no parseable metadata under PATH, a missing or unreadable ruleset in validate mode, or an internal error. The message names the cause and the next step.

What it does​

In generate mode, masking-rules walks the field-level PII classification and emits a masking rule for each field that holds sensitive data: a name field gets a name-shaped mask, an email field gets a synthetic-email mask, a national-ID field gets a format-preserving mask. The output is a ruleset you commit and hand to your sandbox seeding process.

In validate mode, it loads an existing ruleset and checks it against the current schema, reporting any field the classification marks sensitive that the ruleset leaves unmasked. This is the drift check: as new sensitive fields are added, validation catches the ones the ruleset has not caught up to before they reach a sandbox unmasked.

Example​

# Generate a masking ruleset from detected PII.
vulkro-sf masking-rules . --mode generate --format yaml > masking-rules.yaml

# Validate an existing ruleset against the current schema.
vulkro-sf masking-rules . --mode validate --rules ./masking-rules.yaml

# Validate as JSON for a CI seeding gate.
vulkro-sf masking-rules . --mode validate --rules ./masking-rules.yaml \
  --format json > masking-validation.json