Salesforce Code Analyzer v5: Moving Your Pipeline Off sfdx-scanner

TL;DR: Salesforce Code Analyzer v5 replaces the sfdx-scanner plugin. Install it with sf plugins install code-analyzer, swap sf scanner run for sf code-analyzer run, and replace the old --engine and --category flags with a single --rule-selector. The Graph Engine moves under the same command, and engine tuning moves out of CLI flags into a code-analyzer.yml.

If your CI still shells out to sf scanner run, this is the migration to schedule before your next AppExchange submission, not after. The rest of the security review does not change, so this guide sticks to the tooling swap. For what reviewers actually reject and in what order to fix it, see Salesforce Security Review Checklist: What to Fix, In Order.

What changed between sfdx-scanner and Code Analyzer v5?

Same job, new front door. Code Analyzer v5 is a sf plugin that unifies the static analysis engines behind one command and one result format, instead of the engine-by-engine flags v4 exposed. Three differences matter when you migrate:

• One command surface. sf code-analyzer run covers the engines that used to be split across sf scanner run and sf scanner run dfa, so the Graph Engine is no longer a separate invocation with its own flags.
• Selectors instead of engine and category flags. You ask for rules by name, tag, engine or severity through --rule-selector rather than combining --engine with --category.
• Configuration in a file. Engine tuning that used to live in CLI flags and per-engine config paths now belongs in a code-analyzer.yml, which you commit alongside the code it governs.

How do you install and run it?

Install the plugin, then run it against your workspace:

sf plugins install code-analyzer
sf code-analyzer run --workspace . --view detail

Generate a starting configuration once and commit it, so every developer and every CI job analyses with the same rules:

sf code-analyzer config --output-file code-analyzer.yml

Before you trust a selector, list what it resolves to. This is the fastest way to catch a migration that silently narrowed your coverage:

sf code-analyzer rules --rule-selector Security

How do you translate your existing commands?

Work through your pipeline definitions and your local scripts in one pass:

• sf scanner run --target force-app becomes sf code-analyzer run --workspace force-app.
• --engine pmd --category Security becomes --rule-selector pmd:Security, or just --rule-selector Security when you want that tag across every engine.
• sf scanner run dfa becomes a selector on the Graph Engine inside the normal run, rather than its own subcommand.
• --format plus --outfile become --output-file, where the extension picks the format. Use --output-file results.sarif if you upload findings to your host's code scanning view.
• Per-engine config flags become entries in code-analyzer.yml. Move them rather than reproducing them as flags.

Do not migrate a suppression list by hand-copying rule names. Rule identifiers moved with the engines, so re-derive your exclusions from a fresh sf code-analyzer rules listing and delete the ones that no longer resolve.

How do you gate CI on the results?

Use --severity-threshold. The command exits non-zero when it finds a violation at or above the level you pass, which is what turns the scan from a report into a gate:

sf code-analyzer run --workspace . \
  --rule-selector Security \
  --severity-threshold 3 \
  --output-file results.sarif

Set the threshold where your codebase is today, not where you want it, then tighten it once the backlog clears. A gate that fails on every pull request from day one gets disabled within a week, and a disabled gate catches nothing.

What does this migration not change?

Code Analyzer covers the code inside your package. The rest of the submission evidence is untouched by the version swap:

• The source scan you run through the Partner portal still runs separately.
• Any external endpoint your package calls still needs its own dynamic scan report. See Running Your Own Dynamic Scans After Chimera.
• Findings you consider false positives still need a written justification per finding. How to Document False Positives for the Salesforce Security Review covers the format.

Migrating a pipeline you did not build, on a deadline? Tekunda builds and packages AppExchange products as a Salesforce PDO, security review included. Tell us where your pipeline is stuck and we will scope the swap.

FAQ

Is sfdx-scanner still supported?

Treat it as the previous generation. Code Analyzer v5 is the successor, and new rules and engine updates land there, so a pipeline left on the old plugin quietly falls behind on coverage.

Do my results change after migrating?

Expect them to. Selectors resolve to a different rule set than your old engine and category combination, and severities are normalised across engines. Run both versions once, side by side, and diff the findings before you delete the old job.

Where do I put engine settings now?

In code-analyzer.yml, committed to the repo. Generate a starting file with sf code-analyzer config and edit from there rather than writing one from scratch.

Can I run it in a pipeline without the whole Salesforce CLI?

It is a sf plugin, so the CLI is a prerequisite. Install the CLI and the plugin in your build image rather than on every run, or the install dominates the job time.