Salesforce Code Analyzer is Salesforce's own code scanner for Apex, Visualforce, Lightning components, JavaScript and Flows. Version 5 bundles eight engines behind one CLI command, sf code-analyzer run. If your SaaS company ships a managed package on AgentExchange (formerly AppExchange), Salesforce requires a Code Analyzer report with your security review submission, so this scan decides how many review rounds your team sits through. For an independent software vendor (ISV), skipping it means CRUD and injection gaps surface in a failed review instead of a pull request.
For a review, the command Salesforce documents is sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html. Keep both selectors. When we scanned a test package with Code Analyzer 5.16.0 on October 22, 2026, the AppExchange selector held 37 PMD rules and none of them was the CRUD check. The CRUD, SOQL injection and insecure endpoint findings all came from Recommended:Security. The selector is still called AppExchange, even though Salesforce launched AgentExchange in place of AppExchange in April 2026.For a SaaS company, the security review is the gate between a finished managed package and enterprise buyers evaluating your product inside Salesforce. This guide covers the scans your team runs, and the section on the security review covers which reports each submission needs and where Appnigma's marketplace apps team can take the package build and review prep off your engineers.
Updated October 2026. Rewritten for Code Analyzer 5.16.0, with the documented install command, the scan reports each submission type needs, the Agent Skills that replaced MCP, and results from a real test scan. The October 23 update added the UIBundle engine, the ESLint config change, the AgentExchange name, and how Code Analyzer compares with other Salesforce static analysis tools.
The eight engines in v5 and what each one needs to run
Code Analyzer v5 ships with eight engines, and the Engines page says they're all enabled by default. You select an engine by its key in --rule-selector.
| Engine | Key | What it checks |
|---|---|---|
| PMD | pmd | Apex and Visualforce rules. Includes the PMD AppExchange rules |
| Copy Paste Detector | cpd | Duplicated blocks of code across files |
| ESLint | eslint | JavaScript and TypeScript, including Lightning web components |
| RetireJS | retire-js | Third-party JavaScript libraries with known vulnerabilities |
| Regex | regex | Patterns you define, such as hardcoded tokens |
| Flow Scanner | flow | Security issues in Salesforce Flows |
| Salesforce Graph Engine | sfge | Data-flow analysis of Apex. Still labeled Developer Preview |
| ApexGuru | apexguru | Scans of Apex in a connected org, added as a CLI engine in v5.16.0 |
Version 5.16.0 also added a ninth engine, UIBundle, in Developer Preview. Per the release notes, it checks compiled JavaScript output against its submitted source and runs alongside ESLint, PMD and RetireJS. The Engines page doesn't list it yet.
Three prerequisites decide which engines actually run on your machine. PMD, CPD and Graph Engine need JDK 11 or later. Flow Scanner needs Python 3.10 or later. ApexGuru needs an org you're logged in to, passed with --target-org. The install guide lists the JDK and Python requirements, and the ApexGuru engine page covers the org connection.
A missing prerequisite doesn't stay quiet. Our test machine had Python 3.9, and the scan reported Flow Scanner's startup failure as finding number one, severity 1 (Critical), rule flow:UninstantiableEngineError. In a CI job with a severity threshold, that one line fails the build even when your code is clean. Install Python 3.10 or later, or turn the engine off in your config file.
Which scans does the AgentExchange security review need?
Code Analyzer is one of the scans an AgentExchange (formerly AppExchange) security review submission can require. The review sits on the critical path of a managed package launch. Salesforce estimates 1 to 2 weeks to verify a submission and 3 to 4 weeks for the first test, and a failed test means fixing, rescanning and waiting again, per the ISVforce guide's How It Works page. Clearing scanner findings before you submit is the cheapest way to avoid a second round.
Which reports you upload depends on what you're submitting, per the ISVforce guide.
| Report | When it's required |
|---|---|
| Code Analyzer (HTML) | Your solution is a managed package. It's in addition to the Checkmarx scan |
| Checkmarx Source Code Scanner | Any submission with a Salesforce package or component. Not required for mobile clients or API solutions |
| DAST scan (dynamic testing of your running endpoints) | Your solution connects to any non-Salesforce domain |
| False positive document | You're leaving any flagged finding unfixed |
So a managed package that calls outside services submits Code Analyzer, Checkmarx and DAST reports. A native package with no external endpoints submits Code Analyzer and Checkmarx. The rules come from Test Your Entire Solution and the Code Analyzer scan page.
Scan order from first build to submission
Treat scanning as a release step, not a last-minute task. This is the order the ISVforce guide implies.
- Add Code Analyzer to CI early with a loose severity threshold, so findings show up in pull requests months before you submit.
- Before you submit, run the documented command against the exact package version you'll submit, fix what you can, and rescan until only explainable findings remain.
- Run the Checkmarx scan in the Partner Security Portal just before submission. Three runs per package version come with the review fee, so don't spend them on early builds.
- If the package calls any non-Salesforce domain, run a DAST scan against those endpoints, after getting permission from whoever owns them.
- Write one false positive document that covers every finding you didn't fix, across all the reports.
- Upload the reports and the document in the submission wizard.
Where the Checkmarx and DAST reports come from
The Checkmarx Source Code Scanner, a second static scanner that Salesforce hosts, is still current. It runs in the Partner Security Portal (Salesforce's site for ISV partners) against your packaging org, needs the Author Apex permission, and three runs per package version come with the review fee. We cover the setup in how the Checkmarx Source Code Scanner works.
For the DAST report, Salesforce's own Chimera scanner is gone. The Partner Security Portal FAQ says Chimera is no longer available and its reports couldn't be accessed after June 16, 2025. Partners now run a DAST tool of their choice, such as OWASP ZAP or Burp Suite.
What our test scan found, and the fixes that cleared it
Salesforce doesn't expect a perfect Code Analyzer report. The ISVforce guide says scans don't need to be "100% passing." Run the scan from the top-level folder of the package version you're submitting, fix every violation you can, rescan, and upload the HTML report.
Here's what that loop looked like on our test package, a small Apex class with four deliberate problems and one Lightning web component.
| Finding | Severity | Selector it came from |
|---|---|---|
| pmd:ApexSOQLInjection (user input concatenated into a query) | 2 High | Recommended:Security |
| pmd:ApexCRUDViolation (query and update) | 2 High, twice | Recommended:Security |
| pmd:ApexInsecureEndpoint (http:// callout) | 2 High | Recommended:Security |
| pmd:ApexSuggestUsingNamedCred | 2 High | Recommended:Security |
| eslint:@lwc/lwc/no-inner-html | 2 High | Recommended:Security |
| pmd:AvoidHardcodedCredentialsInHttpHeader | 3 Moderate | AppExchange |
Every finding cleared with standard fixes. We used a bind variable with WITH USER_MODE on both queries, Database.update(inv, AccessLevel.USER_MODE) for the write, a callout: endpoint backed by Named Credentials instead of a header token, and textContent instead of innerHTML. The rescan returned "Found 0 violations." The SOQL and permission findings matter most. CRUD and FLS checks confirm the running user may create, read, update or delete an object (CRUD) and see or edit each field (field-level security, FLS). Missing them was the top reason partners failed review in Salesforce's 2023 ranking of review findings, by a significant margin.
Explaining unfixed findings in a false positive document
A false positive is a flagged item that isn't exploitable in your context, such as a Graph Engine path your code already guards elsewhere. Don't switch the rule off to hide it. Salesforce asks for a document that explains why each flagged item poses no risk, and its example responses page uses three columns.
| Reported Vulnerability | Location | Response |
|---|---|---|
| ApexFlsViolation (READ, Invoice__c.Status__c) | InvoiceSync.cls, line 11 | Example only. The method is called solely by an admin page gated by a permission set that grants read on Status__c |
| Insecure Software Version | moment.js | No user input flows into moment parsing (Salesforce's own sample row) |
Name the rule and the exact file and line. Then give the reason in terms a reviewer can check, such as the data path, the control that blocks it, or why an attacker can't control the input. You upload the document in the submission wizard's Upload Documentation step, alongside the scan reports.
If you'd rather hand off the package build and review prep, Appnigma's marketplace apps projects cover the managed package, listing preparation, and security review preparation and responses. Appnigma is built by ex-Salesforce engineers. Salesforce controls approval and queue timing, so no partner can promise a pass date.
Read more: Salesforce security review checklist
Installing the CLI plugin and running a scan
Code Analyzer is a plugin for the Salesforce CLI. Install it with the package name the docs use.
sf plugins install @salesforce/plugin-code-analyzerIt's also a just-in-time (JIT) plugin, so running any sf code-analyzer command installs it on first use. The shorter sf plugins install code-analyzer isn't the documented form. Rerun the install command to update, and check your version with sf plugins --core.
Code Analyzer has three main commands.
List the rules a selector matches:
sf code-analyzer rules --rule-selector Recommended:SecurityScan the current folder with the default Recommended rules:
sf code-analyzer runWrite a commented starter config file:
sf code-analyzer config --output-file code-analyzer.ymlA bare sf code-analyzer run uses the Recommended rules, scans the current folder, prints a table, and picks up a code-analyzer.yml in that folder if one exists. In our test that default set was 300 rules from ESLint, PMD, Regex, RetireJS and CPD.
These are the run flags you'll use most.
| Flag | What it does |
|---|---|
| --workspace | Files or folders to analyze. Accepts globs and defaults to the current folder |
| --target | Narrows the scan to a subset of the workspace |
| --rule-selector | Which rules to run, by engine, tag, rule name or severity |
| --severity-threshold | Exits with a non-zero code when a finding meets or beats this severity |
| --output-file | Writes results. The extension sets the format. Repeat it for several files |
| --view | table (the default) or detail |
| --config-file | Points to a config file outside the current folder |
| --target-org | The org ApexGuru scans |
| --include-fixes | Adds fix code to JSON, XML or SARIF output where the engine supplies one (currently ESLint) |
Output files can be HTML, CSV, JSON, XML or SARIF. Severity runs from 1 (Critical) through 2 (High), 3 (Moderate) and 4 (Low) to 5 (Info).
Combining engines, tags and severities in --rule-selector
Inside one --rule-selector value, a colon means AND and a comma means OR. A number matches a severity. If you use parentheses, wrap the whole value in double quotes.
PMD rules tagged Security:
sf code-analyzer run --rule-selector pmd:SecurityPMD or RetireJS rules tagged Performance or Security, at severity 2 or 3:
sf code-analyzer run --rule-selector "(pmd,retire-js):(Performance,Security):(2,3)"Critical findings only:
sf code-analyzer run --rule-selector 1Repeating the flag adds rule sets together. In our test, AppExchange matched 37 rules and Recommended:Security matched 22. Passing both flags matched 59. Joining them with a colon instead (AppExchange:Recommended) matched zero. One Salesforce guide page describes repeated flags as AND, but the CLI behaves as OR. To see exactly what a selector covers, run sf code-analyzer rules with it before you scan.
Setting engines and rule severities in code-analyzer.yml
Code Analyzer reads code-analyzer.yml or code-analyzer.yaml from the root of your workspace, and so does the VS Code extension. The configuration guide covers every key. sf code-analyzer config writes a full starter file. Ours was 417 lines, mostly comments.
You rarely need that much. This is the config we used for the test scan. It turns off Flow Scanner on a machine without Python 3.10, skips dependency folders, and raises one rule's severity.
engines:
flow:
disable_engine: true
ignores:
files:
- "**/node_modules/**"
rules:
pmd:
ApexSuggestUsingNamedCred:
severity: "Critical"Rule overrides take severity, tags or disabled, and severity accepts the number or the name. Two details catch people out. A custom regex rule needs the global modifier, so /Todo/gi works and /Todo/i doesn't. If a file sits in both --target and ignores, the ignore wins.
Seeing findings in VS Code while you write
The Salesforce Code Analyzer extension for VS Code shows findings in the Problems tab as you work. It needs VS Code 1.90 or later and still uses the CLI plugin underneath, so install that first. The VS Code guide lists the commands, such as "SFDX: Scan Current File with Code Analyzer". Per the release notes, the extension now supports only Code Analyzer v5.
One limit matters for ISVs. The extension's scan buttons don't produce the report you upload for review. Salesforce's AppExchange page says to run the CLI command, in VS Code's terminal or any other.
Blocking pull requests on high-severity findings in CI
Pair --severity-threshold with a SARIF output file. SARIF (Static Analysis Results Interchange Format) is a standard JSON format for scanner results. The threshold fails the job on real findings, and most code hosts read SARIF to annotate the pull request. Salesforce also publishes a Code Analyzer GitHub Action. Since 5.16.0, JavaScript ESLint config files such as eslint.config.js no longer load automatically, per the release notes, so a CI job that relied on one has to set eslint_config_file in code-analyzer.yml.
sf code-analyzer run --workspace force-app --rule-selector Recommended:Security --severity-threshold 2 --output-file results.sarifOn our test package, a threshold of 2 ended the run with exit code 1 and the message "5 violations met or exceeded the severity threshold of High." Start the threshold loose on a codebase that's never been scanned. A first run can return hundreds of findings, and a gate that blocks everything on day one tends to get switched off. Fail on severity 1, fix that tier, then move the threshold to 2.
Replacing sf scanner run when you move from v4 to v5
Salesforce retired Code Analyzer v4 in August 2025 and no longer supports it. If your pipeline still calls sf scanner run, it's running a retired scanner that won't get rule updates. The migration guide maps the old commands.
| v4 | v5 |
|---|---|
| sf scanner run | sf code-analyzer run |
| sf scanner run dfa | sf code-analyzer run --rule-selector sfge |
| sf scanner rule list | sf code-analyzer rules |
| --category Security | --rule-selector Security |
| --engine pmd --category Security | --rule-selector pmd:Security |
| --projectdir | --workspace |
| --pmdconfig | engines.pmd.custom_rulesets in code-analyzer.yml |
Graph Engine no longer has its own command, and its seven rules are tagged DevPreview rather than Recommended. A default sf code-analyzer run won't touch them. Select sfge explicitly.
Graph Engine also needs an entry point. On our test class, --rule-selector sfge returned zero findings for two methods that read and update records with no permission checks. After we added @AuraEnabled to those methods, the same scan reported ApexFlsViolation for the READ and the UPDATE on Invoice__c.Status__c. Graph Engine follows data from entry points, the methods a user or another system can call directly, such as Aura-enabled methods, so a clean result on a utility class doesn't prove the code is safe.
Running scans from Claude Code, Cursor and other AI assistants
Salesforce now offers Code Analyzer through Agent Skills, packaged instructions an AI coding assistant loads to run a tool correctly. The dx-code-analyzer-run skill turns a plain-language request into a valid CLI command, and it installs in Claude Code, Cursor and Windsurf from the Salesforce Skills Library (@forcedotcom/sf-skills), per the skills guide.
The earlier route, the code-analysis toolset in the Salesforce DX MCP Server (MCP is the Model Context Protocol for connecting tools to AI assistants), is on its way out. Salesforce's MCP page says "MCP is no longer supported as of June 2026" and asks users to move to skills. Even before that, the MCP tool handled at most 10 files per run and only five of the eight engines.
What a source code scan can't catch
Code Analyzer reads source files. Apart from ApexGuru, which reads Apex in a connected org, it doesn't run your application or call your endpoints. That leaves gaps you have to cover another way.
| Gap | What covers it |
|---|---|
| External endpoints and runtime behavior | A DAST scan with a tool such as OWASP ZAP or Burp Suite |
| The Checkmarx report the review requires | The Source Code Scanner in the Partner Security Portal |
| Findings that aren't real in your context | Your false positive document |
| Graph Engine coverage | Only paths from entry points, and the engine is still in Developer Preview |
| Flow scanning on machines without Python 3.10 or later | Install Python, or the engine reports a Critical error |
How does Code Analyzer compare with Checkmarx, PMD and other Salesforce scanners?
Code Analyzer is the free baseline for Salesforce static analysis. Salesforce maintains it, it bundles PMD with its other engines, and for a managed package its report is part of the security review submission whatever else you run. The second scan Salesforce asks for, the Checkmarx Source Code Scanner, runs in the Partner Security Portal, with three runs per package version included in the security review fee.
Commercial tools sit on top of that baseline and don't replace either report. What they add, in their vendors' words, is mostly about running analysis across a team over time, such as dashboards and history, tracking new issues separately from existing ones, wider metadata coverage, gates in a release pipeline and, for some, dynamic testing.
| Tool | What it scans, per the vendor | How it runs | Security review role | License |
|---|---|---|---|---|
| Salesforce Code Analyzer | Apex, Visualforce, Lightning, JavaScript, HTML, CSS, Flows | CLI plugin, VS Code, GitHub Action | Report required for managed packages | Free, open source |
| Checkmarx Source Code Scanner | Code in your packaging org | Hosted in the Partner Security Portal | Report required for packages and components | Three runs included in the review fee |
| PMD | Apex and Visualforce, plus other languages | CLI, IDE plugins, CI | Runs inside Code Analyzer | Free, open source |
| AutoRABIT CodeScan | Apex, Visualforce, Lightning web components, metadata | Cloud or self-hosted, IDE plugins, CI | None stated | Commercial |
| DigitSec | Custom code (SAST), plus DAST, dependency and configuration review | SaaS | None stated | Commercial |
| Flosum Code Scan | Apex PMD rules, with an option that adds Flow and TypeScript checks | Step in Flosum pipelines | None stated | Part of Flosum |
| Gearset Code Reviews (formerly Clayton) | Over 300 metadata types, including Apex, Flows, Lightning, profiles and permission sets | SaaS with Git providers, VS Code | None stated | Commercial |
| Quality Clouds | Apex, SOQL, Flows, Lightning web components and configuration | SaaS outside the org, VS Code, DevOps Center, Copado | None stated | Commercial |
| SonarQube | Apex and Lightning components, can import PMD reports | Self-hosted server or cloud, IDE extension | None stated | Apex in paid editions |
If you're an ISV getting ready for review, start with Code Analyzer and the Checkmarx scan, since those are the two reports Salesforce reads. If your team already runs SonarQube or a DevOps platform such as Copado or Gearset, check whether it can run Code Analyzer as one of its gates, so developers see the same findings the review will.
Frequently Asked Questions
What is Salesforce Code Analyzer?
A free Salesforce CLI plugin that scans Apex, Visualforce, Lightning components, JavaScript and Flows. Version 5 bundles eight documented engines, including PMD, Flow Scanner and Graph Engine, plus a UIBundle engine in Developer Preview since 5.16.0.
How do I install Salesforce Code Analyzer?
Run sf plugins install @salesforce/plugin-code-analyzer, or run any sf code-analyzer command and it installs itself. PMD, CPD and Graph Engine need JDK 11 or later, and Flow Scanner needs Python 3.10 or later.
Is Code Analyzer v4 still supported?
No. Salesforce retired v4 in August 2025. Replace sf scanner run with sf code-analyzer run.
Which scan command does the AgentExchange security review expect?
sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html, run from the top-level folder of the package version you're submitting.Does a scan have to be 100% clean to pass the security review?
No. Salesforce says scans don't need to be 100% passing. Fix what you can and explain the rest in a false positive document.
Does Code Analyzer replace the Checkmarx scan?
No. A managed package submits the Code Analyzer report in addition to the Checkmarx Source Code Scanner report, plus a DAST report if it calls non-Salesforce domains.
Why does Graph Engine return no findings?
It isn't in the default Recommended set, so select it with --rule-selector sfge, and it only follows data from entry points such as @AuraEnabled methods. In our test it flagged two FLS problems only after the methods were Aura-enabled.
How do I scan Salesforce Flows for security issues?
Code Analyzer covers Flows through its Flow Scanner engine, selected with --rule-selector flow, which needs Python 3.10 or later. Without Python the scan reports a Critical engine error until you install it or disable the engine.
Do I need a paid scanner to pass the AgentExchange security review?
No. Salesforce asks for the Code Analyzer report, which is free, and the Checkmarx Source Code Scanner report, whose runs are included in the review fee. A commercial tool is a team choice for day-to-day code quality, not a review requirement.
Can Appnigma prepare our managed package for the security review?
Yes. Appnigma's marketplace apps projects include building the managed package, preparing the listing, and handling Salesforce security review preparation and responses. Salesforce decides approval and review timing.
Related Articles
- How the Checkmarx Source Code Scanner works
- Salesforce AppExchange security review, step by step
- Salesforce managed package guide
- Named Credentials and External Credentials in Salesforce
Sources
- Salesforce Code Analyzer engines, Salesforce Developers
- Analyze your code with the CLI, Salesforce Developers
- Customize the configuration, Salesforce Developers
- Migrate from v4 to v5, Salesforce Developers
- Code Analyzer VS Code extension, Salesforce Developers
- Code Analyzer and AppExchange, Salesforce Developers
- Agent Skills for Code Analyzer and MCP tools, Salesforce Developers
- ISVforce Guide: Test Your Entire Solution and Scan with Code Analyzer, Salesforce Developers
- ISVforce Guide: Source Code Scanner and False positive examples, Salesforce Developers
- The top 20 vulnerabilities found in the AppExchange security review, Salesforce Developers Blog, 2023
- Appnigma test scan: Code Analyzer 5.16.0 on Salesforce CLI 2.155.7, Node.js 24, JDK 21, October 22, 2026
