vulkro-sf rules

The rules command family manages the custom and shipped detection rules vulkro-sf runs alongside its built-in detectors. This page covers two additions: rules import-checkmarx, which translates a Checkmarx query export into Vulkro rule YAML, and rules playbook, which lists and shows the shipped playbooks and domain packs (including the healthcare PHI pack HEALTHCARE-PHI-001 through HEALTHCARE-PHI-003).

Synopsis

vulkro-sf rules <subcommand> [args] [flags]

Subcommands

Subcommand	What it does
import-checkmarx <xml>	Translate a Checkmarx CxQL / CxXML query export into a Vulkro custom-rule YAML file.
playbook list	List every shipped playbook and domain pack, with its rule IDs and a one-line summary.
playbook show <id>	Print the full definition of one playbook or domain pack: every rule it carries, what each rule triggers on, and how to fix it.

Flags

Flag	Type	Default	Description
--output, -o <path>	path	stdout	For import-checkmarx: where to write the generated rule YAML. Recommended; use a .yaml extension.
--format <fmt>	enum	table	For playbook list / playbook show: table (human-readable) or json (machine-readable).

rules import-checkmarx <xml>

Reads a Checkmarx query export (a CxQL or CxXML file exported from a CxSAST project) and emits a Vulkro custom-rule YAML file that expresses the same intent against the Apex taint engine. Because Salesforce runs Checkmarx CxSAST as part of the AppExchange Security Review, teams that already maintain Checkmarx queries can carry that investment into their local vulkro-sf runs without rewriting each query by hand.

The translator reads each query's source patterns, sink patterns, and any sanitizer (passthrough) declarations, then maps them onto the Vulkro custom-rule shape. A Checkmarx query that connects a source to a sink through the data-flow graph becomes a Vulkro match.type: compound taint rule: the Checkmarx source list becomes the rule's source, the sink list becomes its sink, and any sanitizer becomes a propagator that clears taint.

# Translate a single exported query file into Vulkro rule YAML.
vulkro-sf rules import-checkmarx apex-soql-injection.cxql -o rules/apex-soql.yaml

# Inspect the translation on the terminal before saving it.
vulkro-sf rules import-checkmarx apex-soql-injection.cxql

Not every Checkmarx construct has a one-to-one Vulkro equivalent. When the translator meets a query element it cannot express (for example a generic C# helper the query depends on, or a flow predicate with no taint-engine analogue), it emits the rule with that element commented out and a # TODO marker naming what needs a human decision, rather than dropping it silently. Review the generated YAML before adding it to your rule set.

rules playbook list

Lists every playbook and domain pack vulkro-sf ships. A playbook is a named group of rules that target one threat theme or one regulated domain, so a team can turn on a coherent set at once instead of enabling rules one at a time.

# List shipped playbooks and domain packs.
vulkro-sf rules playbook list

# Same, as JSON for a config pipeline.
vulkro-sf rules playbook list --format json

The output names each playbook, the rule IDs it carries, and a one-line summary. The shipped healthcare PHI pack, for example, lists as:

healthcare-phi   Healthcare PHI exposure pack
                 HEALTHCARE-PHI-001  PHI field reaching an unauthenticated or guest surface
                 HEALTHCARE-PHI-002  PHI written to a debug log or error message
                 HEALTHCARE-PHI-003  PHI sent to an external processor without a covered agreement

rules playbook show <id>

Prints the full definition of one playbook. For each rule it carries, the output shows what the rule triggers on, why it matters, and how to fix it, so a reviewer can read the whole pack before enabling it.

# Show the healthcare PHI pack in full.
vulkro-sf rules playbook show healthcare-phi

The healthcare PHI pack carries three rules:

• HEALTHCARE-PHI-001: a PHI-bearing field (a field the pack's catalog classifies as protected health information) reaches an unauthenticated or guest-accessible surface: a public Apex REST method, a guest-user Visualforce page, or an @AuraEnabled method with no access check. Fix by enforcing CRUD and FLS on the read and restricting the surface to authenticated, entitled users.
• HEALTHCARE-PHI-002: a PHI field flows into a System.debug statement or an exception message rendered to the caller. PHI must not land in debug logs or error output. Fix by removing the field from the log line or redacting it before logging.
• HEALTHCARE-PHI-003: a PHI field flows to an external processor (a Named Credential endpoint or outbound callout) without a covered Business Associate Agreement. This pairs with the compliance baa-verify registry check: the rule flags the data flow in source, and baa-verify confirms the destination is covered. Fix by routing the data only to processors with a signed, in-window agreement.

Exit codes

• 0 - success. For import-checkmarx: the YAML was produced. For playbook list / playbook show: the requested playbook was found and printed.
• 1 - reserved for the playbook subcommands when a requested playbook ID does not exist (the message lists the valid IDs).
• 2 - error: bad arguments, an unreadable or malformed Checkmarx export, an unwritable output path, or internal crash. The error message names the cause and the next step.