Static Code Analysis
  • 07 Jun 2022
  • 3 Minutes to read
  • Contributors
  • Dark
    Light

Static Code Analysis

  • Dark
    Light

verview

Static code analysis, or static analysis, is a software verification activity that analyzes source code for quality, reliability, and security without executing the code. Using static analysis, you can identify defects and security vulnerabilities that could compromise the safety and security of your application. Static analysis can be a cost-effective approach to measuring and tracking software quality metrics without the overhead of writing test cases or instrumenting your code.

Static analysis is generally good at finding coding issues, such as:

  • Programming errors
  • Coding standard violations
  • Undefined values
  • Syntax violations
  • Security vulnerabilities

Run Static Code Analysis

To run a static code tool on your Salesforce Org or Version Control Branch, follow the below steps:

  1. Hover your mouse over the REPORTS module and choose the option: STATIC CODE ANALYSIS
  2. Click on the NEW STATIC CODE ANALYSIS button at the top right corner of the screen.
  3. On the next screen, enter a Label Name.
  4. Choose Source as Salesforce Org or Version Control.
    • For Salesforce Org selection, choose the Salesforce Org for which the SCA will be performed.
    • For Version Control selection, choose your source Repository and Branch.
  5. Select the SCA tool from the drop-down list. For example, ApexPMD, Checkmarx, SonarQube, or CodeScan.
    Note:

    Before running the Static Code Analysis tool, you must enable them under the My Account > Plugins section.

    SCA-Supported Metadata Types:
    • For ApexPMD/Lint, Checkmarx/Lint, SonarQube/Lint: Apex Classes, Apex Triggers, Apex Pages, AuraDefinitionBundle, LightningComponentBundle.
    • For Codescan/Lint: ApexClasses, ApexPages, ApexTriggers, AuraDefinitionBundle, CustomObjects, Flow, LightningComponentBundle, PermissionSets, Profiles, Settings, SharingRules, Workflows.
  6. Select the recipients for the alert under the Notifications field. Multiple recipients can be added here.
  7. Next, choose the frequency for SCA to run, i.e., daily, weekly, or at any specific interval. For example, if you want the SCA tool to run daily at 10 AM, select the Daily option and set the fixed time to 10.

  8. Click on SAVE.
  9. Upon confirmation, you'll be redirected to the home page, where you can find your recently configured SCA.

Additional options on this page

  1. Running On-demand SCA: To run the SCA tool before the scheduled time frame, click on the Run () button.

  2. Log: Click on the Log () icon to find the detailed log report.

  3. SCA Result: ARM generates a detailed SCA report whenever you run static code analysis. Additionally, Lint runs by default, irrespective of the SCA tool you choose. Lint analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. (Lint Report will display information about AuraBundle components only.) This report will have info about the reviewed files and the related violations. Click on each file to view its related violations at the bottom right side of the page. If you click on any violation, it will take you to the respective line (in the black screen on the right side) where the violation occurred.

  4. Download SCA Report: Click on the Download () icon to download the report in CSV format on your local device.
  5. Delete SCA process: Click on the Delete () icon to delete the SCA process configured for your org/anch. This cannot be undone.
  6. View the SCA run details: To view the list of SCA runs to date along with individual SCA results, click on the Label Name. The main screen shows the last details of the SCA run.

Point to Note:

We generated a new project using the master branch for every ARM run (CI build, custom deployment, EZ-commit, EZ-merge, static code analysis report) with CodeScan and SonarQube. However, this was causing trouble.

So, now we’re utilizing ARM_<sforgname> or ARM_<reponame_branchname> as the project’s unique name, and we’re creating short-lived branches for each run. Thus, the technique builds a single project for a single Salesforce Org or Version Control Repo/branch and then executes the analysis on the short-lived branches.

Naming convention for the short-lived branches: <cijobname_build#>, <customdeploylabel_iteration#>, <ezcommit labelname>, <merge label>, <reportname_iteration>

The short-lived branches are active for a limited time (30 days by default, depending on SonarQube/CodeScan configuration), after which they will be automatically deleted. The report will remain on ARM. However, the branch will be removed from the SonarQube/ CodeScan side.


Was this article helpful?

What's Next
>