Overview

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.

   

   • Select Source as Salesforce org, then new options become available:

• When performing a prevalidation commit with SCA analysis in DX format on the respective SF Org and package directory, consistency with previously executed analyses for this SF Org and related directory is crucial. Choosing the appropriate comparison branch is essential for accurate evaluations.

• Existing analyses lack branch tracking, limiting the effectiveness of the fix to new analyses if transitioning from a base scan in mdapi to DX, project deletion, and rerun become necessary for recreation in the DX source structure.

• Building on point #1, achieving the described outcome is unattainable with different structures but aligns seamlessly within a single structure per project.

• Depending on the need, a Salesforce or a repository must be bonded with either mdapi or DX source structure but not with both.

5. Select the SCA tool from the drop-down list. For example, CodeScan, ApexPMD, Checkmarx, Salesforce Scanner, or SonarQube.

1. The list of respective Metadata Types is displayed for the selected SCA tool. By default, all are selected. You can unselect certain metadata types as per your requirements. Supported Metadata Types:

   • For ApexPMD, Checkmarx, SonarQube: Apex Classes, Apex Triggers, Apex Pages, AuraDefinitionBundle, LightningComponentBundle.

   • For Codescan, Salesforce Scanner: ApexClasses, ApexPages, ApexTriggers, AuraDefinitionBundle, CustomObjects, Flow, LightningComponentBundle, PermissionSets, Profiles, Settings, SharingRules, Workflows, StaticResource.

2. For CodeScan or SonarQube, choose the Baseline Branch if you want to run comparisons between reports.

3. Select the recipients for the alert under the Notifications field. Multiple recipients can be added here.

4. 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.

1. Click on SAVE.

2. Upon confirmation, you'll be redirected to the home page, where you can find your recently configured SCA.

   

Additional options on this page

1. SCA Result: ARM generates a detailed SCA report whenever you run static code analysis. 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. 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.

   

Points to Note:

We are utilizing <sforgname> or <reponame> as the project’s unique identifier, 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.

The naming convention for the short-lived branches: <jobname_branchname>

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.

Scans will run only on the source, whether the source is VC Repo or SF Org. The scan results will then be available in the Reports module. Users can trace the job that is run in ARM to the scan using the unique identifier.