Skip to main content

vulkro-sf presubmit

Runs the pre-submit security checklist: a focused set of ten checks that should pass before a Salesforce change is pushed for review or merged. The command is built for the developer loop and the CI gate, where the question is not "audit everything" but "is this change safe to submit?" It runs locally with no network calls.

Synopsis​

vulkro-sf presubmit [PATH] [flags]

PATH defaults to the current directory and should point at the SFDX project (or retrieved metadata) for the change under review.

Flags​

FlagTypeDefaultDescription
--format <fmt>enumtableOutput format: table (human-readable checklist with per-check PASS / FAIL), json (machine-readable result for a CI gate), or sarif (SARIF 2.1.0 for code-scanning dashboards).
--metadata-onlybooloffSkip SFDX project detection; treat PATH as a retrieved metadata folder with no sfdx-project.json.

What it does​

The checklist evaluates ten checks, SF-PRESUBMIT-001 through SF-PRESUBMIT-010, each rendered with a PASS or FAIL result so a reviewer (or a CI job) can confirm the change clears every gate before it is submitted. A FAIL on any check sets the findings exit code so the gate can block the submission.

The checks cover the pre-submit-critical surface: authorization enforcement on the changed code, injection sinks, sharing posture, secrets introduced in the diff, exposed external surfaces, dependency and supply-chain integrity, and agent-action guardrails. Each FAIL names the component and the remediation so the developer can fix it in the same loop rather than discovering it later in a full review.

Example​

# Run the pre-submit checklist and print the table.
vulkro-sf presubmit .

# JSON result for a CI gate that blocks on any FAIL.
vulkro-sf presubmit . --format json > presubmit.json

# SARIF for code-scanning annotations on the pull request.
vulkro-sf presubmit . --format sarif > presubmit.sarif

A common CI pattern treats exit code 1 as a hard block: the job fails, the pull request cannot merge, and the developer sees the failing checks inline.

Exit codes​

  • 0 - every check passed; the change is clear to submit.
  • 1 - one or more checks failed; the change has reportable findings.
  • 2 - error: bad arguments, IO failure, parse error, or internal crash. The error message names the cause and the next step.