Salesforce Code Analyzer v5 puts eight static analysis engines behind a single command. You install one CLI plugin, run sf code-analyzer run, and PMD, ESLint, RetireJS, the Graph Engine, Flow Scanner, CPD, a regex engine and ApexGuru all report into one result set.
For anyone heading into the AppExchange security review this is the tool that decides how many submissions you make. PMD ships AppExchange rules written specifically to prepare managed packages for review, so the findings you would otherwise receive weeks later are available on your laptop today.
Version 4 is retired and has been unsupported since August 2025. If your CI still calls sf scanner run, that pipeline is running nothing.
The eight engines
All eight are bundled and enabled by default.
| Engine | Key | What it analyzes |
|---|---|---|
| PMD | pmd | Apex, Visualforce and other supported languages |
| Salesforce Graph Engine | sfge | Apex, with path-based analysis for security vulnerabilities |
| ESLint | eslint | JavaScript and TypeScript |
| RetireJS | retire-js | Third-party JavaScript dependencies with known vulnerabilities |
| Flow Scanner | flow | Salesforce Flows, reporting security issues |
| CPD | cpd | Blocks of duplication across files |
| Regex | regex | Patterns you define yourself |
| ApexGuru | apexguru | Real-time scans against a connected org |
Two are worth calling out. RetireJS catches the finding that fails more security reviews than its profile suggests: an outdated JavaScript library bundled into a package, flagged by version rather than by anything wrong in your own code. Flow Scanner covers the part of a declarative build that people assume is not reviewed, which it is.
The commands
sf plugins install code-analyzer sf code-analyzer rules sf code-analyzer runThe flags that matter in practice:
| Flag | Use |
|---|---|
| --workspace | Which files or folders to analyze, for example ./force-app |
| --rule-selector | Which rules to run |
| --severity-threshold | Fail the process when violations reach a severity from 1 to 5 |
| --output-file | Write results as CSV, HTML, JSON, XML or SARIF |
| --view | table or detail |
| --target | Narrow to a subset of the workspace |
| --include-fixes | Add actionable fix guidance to findings |
--rule-selector is the flag that turns this from a wall of output into something a team acts on:
sf code-analyzer run --rule-selector Security sf code-analyzer run --rule-selector "pmd:Security:2" sf code-analyzer run --rule-selector "(pmd,retire-js):Security"The Graph Engine no longer has a separate command. In v4 it ran through its own invocation, and in v5 it is an engine like any other, selected through --rule-selector. This is the single most common reason a migrated pipeline silently stops doing path-based analysis.
Wiring it into CI
The combination worth writing down is --severity-threshold plus --output-file with SARIF output. The threshold makes the build fail on real findings rather than producing a report nobody opens, and SARIF is what code hosting platforms read to annotate a pull request directly.
Start the threshold loose and tighten it. A codebase that has never been scanned will produce hundreds of findings on the first run, and a pipeline that fails on all of them from day one gets switched off in a week. Fail on the highest severity, fix that tier, then move the threshold.
What it does and does not do for the security review
Code Analyzer is static analysis. It reads your code. It never runs your application.
| Requirement | Code Analyzer covers it |
|---|---|
| Apex code-level findings, including CRUD and field-level security enforcement | Yes, through PMD and the Graph Engine |
| Vulnerable third-party JavaScript | Yes, through RetireJS |
| Flow security issues | Yes, through Flow Scanner |
| Runtime and application-layer testing | No |
| The false positive document | No, you write it |
That last row is where submissions come apart. A static scanner reports findings, and a proportion of them are not real in your context. Explaining each one is a document you produce, and it is a normal part of the submission rather than a sign something went wrong.
The dynamic half is separate work. Since Chimera was retired in June 2025, the dynamic scan is yours to run and report, typically with OWASP ZAP or Burp Suite.
By Salesforce's own ranking, missing CRUD and field-level security enforcement is the leading cause of security review findings. It is also exactly what PMD's AppExchange rules are built to catch, which makes running those rules before submitting the highest-value hour in the whole process.
Running it from an AI coding assistant
Code analysis is one of the toolsets exposed by the Salesforce DX MCP Server, so an assistant in your editor can run the analyzer and read the findings without you leaving the file. That is a genuine improvement over reading a report, because the finding arrives next to the code that caused it. Our guide to the Salesforce MCP server covers the setup.
Frequently Asked Questions
What is Salesforce Code Analyzer?
A Salesforce CLI plugin that runs multiple static analysis engines over your code and reports findings in one result set. Version 5 bundles PMD, the Salesforce Graph Engine, ESLint, RetireJS, Flow Scanner, CPD, a regex engine and ApexGuru, all enabled by default.
Is Salesforce Code Analyzer v4 still supported?
No. Version 4 is retired and has been unsupported since August 2025. Pipelines still calling the old sf scanner commands need migrating to sf code-analyzer run.
How do I run Salesforce Code Analyzer?
Install it with sf plugins install code-analyzer, then run sf code-analyzer run --workspace ./force-app. Add --rule-selector Security to run only security-tagged rules, and --severity-threshold to fail a build when findings reach a given severity.
Does Code Analyzer replace the AppExchange security review?
No. It catches code-level findings before you submit, which reduces resubmissions, but the review also covers runtime behaviour that static analysis cannot see. You still submit, and you still write the false positive document explaining findings that do not apply in your context.
What is the most common security review failure?
By Salesforce's own ranking, missing CRUD and field-level security enforcement in Apex. PMD's AppExchange rules are written to catch it, which is why running those rules before submission is the highest-value check available.
Do I need Salesforce Graph Engine separately?
No, not in v5. The Graph Engine is one of the bundled engines and no longer has its own CLI command. Select it through --rule-selector like any other engine. Pipelines migrated from v4 often lose path-based analysis at exactly this step.
Can Code Analyzer scan Flows?
Yes. The Flow Scanner engine audits Salesforce Flows and reports security issues, and it is enabled by default. A declarative build is still reviewed, so a package built without Apex is not exempt from scanning.
Related Articles
- Salesforce security review guide 2026
- Salesforce AppExchange security review step by step
- Salesforce security review checklist
- Salesforce MCP server explained
Sources
- Salesforce Developers, Salesforce Code Analyzer guide: engine list and keys, default enablement, CLI commands and flags, rule selector syntax, v4 retirement August 2025, Graph Engine command change. 2/ Salesforce Developers Blog, Elevate Your Team's Code Quality with Salesforce Code Analyzer v5, July 2025. 3/ Salesforce Developers, PMD AppExchange rules for managed package security review preparation. 4/ Salesforce Partner guidance on security review findings and the retirement of Chimera in June 2025. Verified 2 September 2026.
