For help with Code Analyzer, read our frequently asked questions.
General Questions
Get answers to the most common, general Code Analyzer questions.
Q: What is Salesforce Code Analyzer?
A: Code Analyzer is a Salesforce CLI plug-in that helps developers write better and more secure code.
To inspect your code, Code Analyzer uses multiple code analysis engines, including PMD, ESLint, RetireJS, and Salesforce Graph Engine. It identifies potential problems, from inconsistent naming to security vulnerabilities, including advanced vulnerabilities such as lack of Create Read Update Delete and Field-Level Security (CRUD/FLS) checks. Code Analyzer conveys these problems with easy-to-understand results. Run the code analyzer on-command in the CLI, or integrate it into your Continuous Integration/Continuous Development (CI/CD) framework so that you can run it against every code change or on a scheduled basis.
Q: Is Code Analyzer part of the AppExchange security review process?
A: Code Analyzer is a standalone product you can run against your code at any time whether you’re preparing for an AppExchange security review or not. It can be executed at-will, it provides results in minutes, and it helps you to find and fix problems quickly.
If you’re planning to list your solution on AppExchange–and if your solution is a managed package–it must pass a security review. In this case, you’re required to scan your solution using Code Analyzer and submit comprehensive scan results in the AppExchange Security Review Wizard. As a result, you can be more confident in the code that you submit for security review. For more information, read Pass the AppExchange Security Review in the ISVforce Guide.
Q: Is Code Analyzer only for Salesforce CLI (sf) projects?
A: Code Analyzer is compatible with any codebase.
Q: Are there prerequisites to use Code Analyzer?
A: You must:
Install Salesforce CLI on your computer.
Use Java v11 or later.
Q: How do I provide feedback on Code Analyzer?
A: Use this form to give us your feedback. And thanks!
A: Use the sf scanner run command in any scripts used by your CI/CD. We also recommend that you:
Keep an artifact of the results. Use the -o | --outfile flag to write your results to a file.
If any violations meet or exceed the provided value, use the -s | --severity-threshold flag. The -v | --violations-cause-error flag has been deprecated.
Questions About Languages
Get answers to the most common Code Analyzer questions about languages.
Q: What languages does Code Analyzer support?
By default, Code Analyzer supports code written in Apex, VisualForce, Java, JavaScript, XML, and TypeScript. To add support for Lightning Web Components, invoke the scanner run command with --engine eslint-lwc.
Q: How do I enable engine X's default rules for language Y?
A: A: That depends on the engine in question. Currently, only PMD has multi-language support. To enable the PMD default rules for a language, add the language’s name to the PMD supportedLanguages array in ~/.sfdx-scanner/Config.json.
If the language isn’t already supported, create an issue in our Github repo.
Q: How do I add new rules for language X?
A: Currently, you can only add custom rules for PMD.
Ruleset files and category files defining only XPath-based rules are referenced as standalone XML files.
Java-based rules must be bundled into a JAR. The JAR/XML can then be added to the rule registry with the scanner rule add command.
If the language isn’t already supported, create an issue on our Github repo.
Questions About Severity Thresholds and Normalization
Get answers to the most common Code Analyzer questions about severity thresholds and normalization.
Q: How do I set a severity threshold for a Code Analyzer run?
A: When you run Code Analyzer with the -s | --severity-threshold flag and a threshold value, Code Analyzer throws an error if violations are found with equal or greater severity than the provided value. Values are 1 (high), 2 (moderate), and 3 (low). The exit code equals the severity of the most severe violation detected. For example, if a violation of severity 2 is found and the threshold is 2 or 3, then the exit code is 2. Using this flag also implicitly invokes the --normalize-severity flag.
Q: How do I normalize severity?
A: PMD, ESLint, and RetireJS all have different scales for reporting the severity of violations. When you run Code Analyzer with the --normalize-severity flag, Code Analyzer normalizes the severity of violations across all invoked engines.
A normalized severity of 1 (high), 2 (moderate), and 3 (low) is returned in addition to the engine-specific severity. Applicable engines include:
CSV
HTML
JSON
JUnit-formatted XML
SARIF-formatted JSON
Table (default output)
XML
For HTML output format, the normalized severity is displayed instead of the engine severity.
Q: How is the severity normalized across all the engines?
A: Severity is normalized across all engines using the values in this table.
Normalized Severity
PMD
ESLint
ESLint-LWC
ESLint-TypeScript
Retire-JS
Salesforce Graph Engine
1 (High)
1
2
2
2
1
1
2 (Moderate)
2
1
1
1
2
2
3 (Low)
3, 4, 5
3
3
Questions About CPD
Get answers to the most common CPD questions.
Q: What languages does CPD support in Code Analyzer?
A: In CPD, Code Analyzer supports Apex, Java, Visualforce, and XML.
Q: How do I know which files weren't included by CPD execution?
A: Execute Code Analyzer for CPD with the --verbose option. Files are filtered first by targetPatterns provided in the ~/.sfdx-scanner/Config-pilot.json file. Files that aren’t handled by CPD are listed in this message: Path extensions for the following files will not be processed by CPD.
Q: I have a file pattern for a supported languages that isn't picked up by CPD. How do I add the file pattern?
A: Add your file pattern to the CPD engine’s targetPatterns in ~/.sfdx-scanner/Config.json. If you rerun Code Analyzer with the CPD engine option and the file is still excluded, create an issue on our GitHub repo.
Q: In my violation messages from the CPD engine, I’m seeing multiple groups of the same checksum. The code fragment is also identical. Why aren’t these made up of the same group?
A: This is a known issue in CPD, and it’s on our backlog to address.
Questions about Salesforce Graph Engine
Get answers to the most common Salesforce Graph Engine questions
Q: Why does analyzing my code using Graph Engine take much longer than all the other engines put together?
Graph Engine builds up the context of the source code in its entirety before it applies rules to capture violations. The number of conditionals, classes to instantiate, and method invocations add to the code complexity. Depending on the code complexity, some projects can take longer to process than others. As a result, we recommend that you focus Graph Engine scans on specific entry points after you do an initial full scan. Also consider running full scans on a scheduled basis, such as nightly, while doing more targeted scans when code changes.
Q: My code isn’t guarded with an Apex script CRUD/FLS check. Is there a way to suppress violations on it?
Questions About Interpreting ApexFlsViolationRule Results
Get answers to the most common Salesforce Graph Enginge ApexFlsViolationRule questions.
Q: My data operation is already protected though not through a CRUD/FLS check. I'm confident that a CRUD/FLS check isn't needed. How do I make the violation go away?
If you determine that the CRUD operation in question is protected by a sanitizer that Graph Engine doesn’t recognize, you can add an engine directive. to let Graph Engine know that the CRUD operation is in fact safe.
Q: I didn’t get any violations. Does this mean my code is secure?
If you didn’t get any violations, one of these states is still a possibility.
Graph Engine didn’t identify any entry points.
Graph Engine ran into errors for all the entry points identified.
Your code is actually secure.
Because #1 and #2 are possibilities, we recommend that you manually make sure that your code is secure.
Questions About OutOfMemory Errors
Get answers to the most common Salesforce Graph Engine OutOfMemory questions.
What factors contribute to an OutOfMemory error?
Multiple factors can degrade Graph Engine’s efficiency and increase the probability of encountering an OutOfMemory error.
With every conditional or method invocation in your code, the number of paths Graph Engine creates increases exponentially.
Your OS type, Java setup, and other processes running on your machine can influence the heap space assigned by Java Virtual Machine (JVM).
If Graph Engine’s execution is interrupted, it returns results from the portion of source code that it analyzed. To capture your results in your own separate file, we recommend that you add the --outfile parameter.
How does Graph Engine determine that a path is too complex?
When Graph Engine traverses a path, it creates instances of ApexPathExpander. The more complex the path, the more instances of ApexPathExpander it creates.
Based on the parameters that you provide in your execution, Graph Engine determines a path expansion limit to cap the number of ApexPathExpander instances that are created. When this limit is reached while analyzing a path, Graph Engine preemptively aborts the analysis on that path with a LimitReached violation. Graph Engine moves on to analyze the next path.
How can you control this limit?
Modify the path expansion limit using either of these methods.
Increase the heap space using --sfgejvmargs -Xmx{size}
Modify the path expansion limit using --pathexplimit {new_limit_number}
Replace this value:
<new_limit_number>: A path expansion upper boundary to limit the complexity of code Graph Engine analyzes
If --pathexplimit is set to -1, there’s no upper-limit check made on the registry.
Note
How is the path expansion limit calculated?
By default, four threads execute within Graph Engine. Based on our analysis, we predict that an OutOfMemory occurs when one of the threads approaches 50% of the allotted heap space. The majority of this 50% is occupied by instances of ApexPathExpander in the registry.
Using this information, the formula to calculate the limit placed by default on ApexPathExpander registry is:
ApexPathExpander registry limit = 50% of Max Heap Space / Average size of ApexPathExpander instance
Retired
As of August 2025, Salesforce Code Analyzer v4 is retired and no longer supported. Use Code Analyzer v5 instead.
j