Salesforce Code Analyzer FAQ

For help with Code Analyzer, read our frequently asked questions.

Get answers to the most common, general Code Analyzer questions.

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.

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.

A: Code Analyzer is compatible with any codebase.

A: You must:

  • Install Salesforce CLI on your computer.
  • Use Java v11 or later.

A: Use this form to give us your feedback. And thanks!

A: You must update the plug-in to the latest version.

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.

Get answers to the most common Code Analyzer questions about languages.

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.

A: Create a request in our Github repo.

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.

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.

Get answers to the most common Code Analyzer questions about severity thresholds and normalization.

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.

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.

A: Severity is normalized across all engines using the values in this table.

Normalized SeverityPMDESLintESLint-LWCESLint-TypeScriptRetire-JSSalesforce Graph Engine
1 (High)122211
2 (Moderate)211122
3 (Low)3, 4, 533

Get answers to the most common CPD questions.

A: In CPD, Code Analyzer supports Apex, Java, Visualforce, and XML.

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.

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.

A: This is a known issue in CPD, and it’s on our backlog to address.

Get answers to the most common Salesforce Graph Engine questions

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.

To learn how, see Engine Directives.

Get answers to the most common Salesforce Graph Enginge ApexFlsViolationRule questions.

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.

If you didn’t get any violations, one of these states is still a possibility.

  1. Graph Engine didn't identify any entry points.
  2. Graph Engine ran into errors for all the entry points identified.
  3. Your code is actually secure.

Because #1 and #2 are possibilities, we recommend that you manually make sure that your code is secure.

Get answers to the most common Salesforce Graph Engine OutOfMemory questions.

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.

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.

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}
  • <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.

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