Release Notes 24.0

Newest CodeScan Releases

CodeScan Cloud

Release Notes 24.0.15

Release Date: 22 December 2024

Summary

CodeScan 24.0.15 is comprised of the following components:

• 1 New Module

• 1 Fix

New Module: nCino

The new nCino module contains rules that scan your metadata and directly query your Salesforce org to find issues and inconsistencies with your nCino configuration. This is a paid module, please contact your account team for more information on pricing.

Please note, a portion of these rules are only available for projects created with CodeScan's direct Salesforce integration due to being based on a query to the Salesforce Org.

nCino Rules Activation:

Create a project analysis with the Salesforce Org that includes nCino objects. Select the nCino specific built in profile and run the project analysis.

User can choose the built in nCino Quality profile consisting of ncino-specific and ncino-goldstandard rules in Apex/Salesfocre metadata or User can add nCino rules to the CodeScan Quality profile. Users can extend existing profiles and activate more rules from Apex and Salesforce Metadata using the "ncino-specific" tag.

Alternatively, they can add the rules directly to newly created quality profiles by selecting the "ncino-specific" tag from the Rules filter, then apply Bulk Change > Activate in > Choose a quality profile.

To learn how to create a custom Quality Profile, see this article.

New nCino Specific Rules:

The following nCino-related rules have been added to the existing Apex/Salesforce Metadata rule sets and are tagged as "nCino-Specific."

Avoid Duplicates in Custom Labels Maintaining unique labels ensures data accuracy and consistency within the nCino platform. By avoiding the creation of multiple labels with the same value, users can rely on the uniqueness of each label for categorization, and analysis purposes.

Collateral Configuration is Null The Collateral Configuration Field on the Collateral Type object should not be null. This will reduce the likelihood of missing or incomplete Collateral information.

Duplicate LookupKeys In the nCino Record Based Configuration, no two records in the configuration should have duplicate LookupKeys. The LookupKey is a critical identifier for these records, and duplicates could lead to data inconsistency and errors in the system.

Fee Template Record Screen Section Ensure that every Fee Template record includes a Screen Section data value. This will reduce the likelihood of missing or incomplete Fee information.

Field History Tracking Check Field History Tracking is limited according to the features in your Salesforce org. By default Field History Tracking can be use to track a maximum of 20 fields per object.

Null LookupKeys In the nCino Record Based Configuration, object records without LookupKeys will cause challenges in data management and processing.

Product Feature record does not exist Ensure that for each nCino Product Object, there is a corresponding Product Feature record. Product Object records existing without an associated Product Feature record, can lead to potential data inconsistencies.

Product Feature Sharing Ensure that each nCino Product Object record is associated with unique Product Feature records. Shared Product Feature records may lead to data inconsistencies and operational challenges.

nCino Custom Components with Duplicate Names Avoiding naming conflicts with existing Managed Package Components minimizes the risk of errors and conflicts within the system, ultimately enhancing system stability and reliability.

nCino Custom Fields with Duplicate Names Avoiding naming conflicts with existing Managed Package Fields minimizes the risk of errors and conflicts within the system, ultimately enhancing system stability and reliability.

nCino Data Integration User Configuration The Data Integration user is authenticated for background jobs such as nightly batched updates of records. Configuring this user’s Permission Sets correctly makes sure that updates by the Data Integration User don't execute additional tasks.

nCino Deprecated Fields Deprecated fields in an nCino environment are labelled with a '-D' to make the deprecation visible when configuring the environment. This rule is to identify the location when deprecated fields are used and should be addressed.

nCino Trigger Handler Framework The Trigger Handler Framework removes logic from Triggers and enforces consistency across the platform. There are many ways to create a Trigger Framework/Factory; however, the nCino Managed Package can save users time and effort. By levering the nCino Trigger Framework, users can control the execution of triggers at runtime, simplify existing customizations and logic.

System Bypass Logic - Flows System bypass logic is required for custom Flows. Checking for the Exclude Flows Permission Set allows the system to cease further processing of the Flow if it is found at the outset. This improves the efficiency of flow execution and reduces unnecessary processing steps.

System Bypass Logic - Triggers System bypass logic is required for custom triggers. Checking for the Exclude Trigger Permission Set allows the system to cease further processing of the Trigger if it is found at the outset. This improves the efficiency of Trigger execution and reduces unnecessary processing steps.

System Bypass Logic - Validation Rules System bypass logic is required for Validation Rules.Checking for the Exclude Validation Permission Set allows the system to cease further processing of the rule if it is found at the outset. This improves the efficiency of Validation Rule execution and reduces unnecessary processing steps.

Fix

1. Fix false positive occuring for the rule "Utilizing Apex Unit Tests with @IsTest(IsParallel)" When IsParallel was being passed with multiple other flags, sometimes the rulewould fire incorrectly. This has been rectified.

Release Notes 24.0.14

Release Date: 04 December 2024

Summary

CodeScan 24.0.14 is comprised of the following eight components:

• 2 Enhancements

• 2 New Rules

• 4 Fixes

Component details are listed in their corresponding sections within this document.

New Features

There are no new features associated with this release.

Enhancements

1. Added “Project Search” in CSV Export Customers with a large number of projects were experiencing a UI issue with the export feature: users who wanted to export issues in CSV format were only able to see the first 100 projects on the list. In this release, we have addressed this issue by adding a search function in the drop-down list to allow users to search for the name of the project they wish to export.

   We verified the added “Project Search” on CSV Export page for multiple scenarios including:

   1. Verified search option functionality with the drop-down list of projects:
   2. Verified the drop-down list shows 20 of the most recently scanned projects by default.
2. Updated the message for Security Hotspot Status “Exception” We recently added a new status type for Hotspots (status = “Exception”). Its intent is to serve as a more accurate status than 'Acknowledged' or 'Open' for issues being treated as exceptions. When we first delivered an “Exception” status, the associated message was: “The code has been reviewed and does not pose a risk currently. Further review is needed at a later date.” Based upon numerous client suggestions, we have enhanced the message to read: "The issue has an approved exception and will be re-reviewed until mitigated or upon exception expiry.”

New Rules

1. New Rule for LWCs: “API Version Is Too Old” This is a new rule to ensure that all Lightning Web Components (LWCs) are using an acceptable API version (including the most current API version). Using outdated API versions can lead to compatibility issues, missed opportunities to leverage new features, and potential security vulnerabilities. This rule aims to streamline the process of identifying and updating LWCs to the latest API version. We recognize that by identifying and updating LWCs to the latest API version, developers are able to maintain higher code quality, reduce the risk of deprecated features, and improve the overall performance and security of the application. Verified the new LWC rule (API Version Is Too Old) for these scenarios:

   • Verified the description, issue type, severity, message, tags, remediation, and parameters of the rule:
   • Verified that a violation is thrown if the API version used is lower than the minimum version allowed:
   • Verified that a violation is thrown if the API version used is higher than the maximum version allowed:
   • Verified that no violation is thrown when the API version is between the minimum and maximum versions allowed.

2. New Rule for APEX: “OuterClassExplicitSharing” Enforces security best practices on classes by ensuring that sharing settings ('with sharing', 'without sharing', or 'inherited sharing') are explicitly declared. This prevents accidental data exposure and enhances code maintainability and compliance with security policies.

   • Name: Outer Class Explicit Sharing

   • Key: OuterClassExplicitSharing

   • Type: Vulnerability

   • Severity: Major

   • Message: Class '{className}' does not have an explicit sharing rule

   • Tags: Convention

   • Remediation: 5 minutes

   Verified the rule: OuterClassExplicitSharing for the following scenarios:

   • Verified the rule’s description, type, severity, message, tag, remediation, key, and name:
   • Verified the rule is not throwing a violation if used with sharing, without sharing, or inherited sharing:
   • Verified that a violation is thrown if not used with sharing, without sharing, or inherited sharing.

NOTE: This rule overlaps with the ClassExplicitSharing rule and will always overlap with violations for outer classes. This rule has been created to:

• Allow for the reporting of this issue as a vulnerability instead of a code smell

• Only flag if sharing settings are missing for outer classes (inner classes that are missing sharing settings will not be flagged—which is opposite of how the ClassExplicitSharing rule works)

If both rules are active, check the violations that were reported and disable one of the rules as necessary.

Fixes

1. Fixed an issue in the CodeScan application in which flagged violations were not being displayed when using the "issues in new code" filter NOTE: This issue only relates to a separate fix stemming from our last release (24.0.13), when we fixed an issue with reference branch analyses. After that fix, however, users were experiencing a new issue, in which flagged violations were not being displayed when using the "issues in new code" filter. The other parts of the CodeScan application were NOT impacted by the reference branch analyses fix in release 24.0.13. As such, all other parts of CodeScan continued to show the accurate new issue count. Regarding this issue, users were unable to navigate to the issues page after running the project analysis. Further, users were not able to see the issues if the user selected any of the issue types (e.g., vulnerability) after running the project analysis. This fix corrects this issue. Users are now able to navigate to the issues page after running the project analysis. Further, users are now able to see the issues if they select any of the issue types (e.g., vulnerability) after running the project analysis.

2. Fixed issue in rule for APEX “sf: {{FieldLevelSecurity}}” {Permissions should be checked before accessing resource}. Previously, this rule was throwing violations that were false positives. This was occurring when a SOSL query having an inner query calls the related Object. The Object needs to be checked by using isAccessible() before accessing its data. NOTE: We addressed a similar issue related to SOQL queries in a previous release. That update has been extended in this release to also include SOSL queries. As per Salesforce documentation, when checking the Access for the inner query object, it allows to check by using __c, but while making inner query on related Objects, it must be in plural and end with __r. This fix corrects this issue. In this enhancement, the Object is checked by using isAccessible() before accessing its data. Verified the rule “Field Level Security Vulnerabilities” for the following scenarios:

   1. Rule is throwing a violation if isAccessible is not checked for the objects used in the inner query:
   2. Rule is not throwing the violation if isAccessible is checked for the objects used in the inner query.

   REMINDER: In the previous release, we added support for SYSTEM_MODE in this rule. A new parameter has been added, allowing users to choose true or false to include or ignore violations related to SYSTEM_MODE. We have verified the rule: FieldLevelSecurity for the following scenarios:

   • Rule is throwing the violation if the object is NOT checked via isAccessible for the methods used in the inner query.

   • Rule is not throwing the violation if the system mode value is set = “true” (and the object IS NOT checked via isAccessible for methods).

   • Rule is not throwing the violation if the system mode value is set = “false” (and the object IS checked via isAccessible for the methods).

3. Fixed issue with Retention Period settings The retention period for project branches in CodeScan was not functioning properly. The UI is able to be set, but it does not affect the cleanup of branches within the project. This setting can be found in Project Settings > General Settings > Housekeeping > Delete inactive branches and PRs after. Also, the text in the “Branches” menu did not reflect the branch retention length change:

   Verified the Retention Period fix for the following scenarios:

   1. In the UI, users are able to set Delete inactive branches and PRs after value:
   2. Users are able to see the same branch retention length value on the Branches & Pull Requests page.
4. Fixed issue with Group Synchronization for SAML connections We uncovered an issue with Group Synchronization during a recent customer implementation. We identified the root cause and a code change delivered in this release fixes the issue. Group synchronization is now working as designed. Further, we verified the Group synchronization option in SAML connection on a customer environment and have reported that this capability is working as expected.

Release Notes 24.0.13

Release Date: 30 October 2024

Summary

CodeScan 24.0.13 is comprised of the following 4 components:

• 1 Enhancement

• 3 Fixes

Component details are listed in their corresponding sections within this document.

New Features

There are no new features associated with this release.

Enhancement

1. Enhancement to Rule for VF: “"vf:AvoidJavaScriptScriptlets” We recognize that using direct <script> tags in components or pages can pose a security risk by increasing the likelihood of cross-site scripting (XSS) attacks. Separately, but importantly, you cannot use “includeScript” to embed an Aura Application to a Visualforce page (as the $Lightning global object is not available if put in a separate .js file as a static resource). To address this, Salesforce details how to “create a component on a Page,” advising you to add your top-level component to a page using $Lightning.createComponent(String type, Object attributes, String domLocator, function callback). Note that this function is similar to $A.createComponent(), but it includes an additional parameter, domLocator, which specifies the DOM element where you want the component inserted. Access the full documentation athttps://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/components_visualforce.htm. Considering both of these items together, we recognize that there was limitation on this rule where customers were getting violations flagged as false positives. This enhancement involves implementing Regex to detect the use of Lightning components within a {{<script>}} tag in Visualforce pages. The rule {{vf:AvoidJavaScriptScriptlets}} should not trigger a violation if only Lightning components are found. However, if any additional lines of non-Lightning code are detected within the script, a violation will be raised. This ensures the proper use of Lightning components while avoiding insecure or outdated practices in scriptlets.

New Rules

There are no new rules associated with this release.

Fixes

1. Fixed issue with reference branch analyses: Branch initially fails the quality gate, then passes on subsequent scans without changes.

   Previously within CodeScan, branches with new code consistently failed the quality gate when they contained unresolved new issues (such as bugs, vulnerabilities, code smells, or security hotspots). This failure persisted until all new issues were addressed, ensuring only clean code passed the quality gate.

   Recently it was reported that "New Code -> Reference Branch" functionality was no longer working as designed, which was impacting quality gate evaluations for new code on branches for some customers. Indeed, branches with new code were initially failing the quality gate if new issues are detected (as expected and desired). However, on subsequent analyses of the same branch—without addressing the new issues—the quality gate was incorrectly passing.

   We recognize that this behavior could result in code potentially being deployed to production despite unresolved issues, as the quality gate no longer blocks the release after the first analysis. As such, a fix has been implemented to ensure the quality gate consistently fails whenever unresolved new issues exist in the code, preventing deployment until all issues are addressed.

   Verified the functionality of reference branch for the following scenarios:

   • Verified the new code of a branch where user is able to see the issues exactly when compared with the reference branch.

   • Verified that the quality gate failed status if the new branch has any new code compared to the reference branch.

   • Verified that the quality gate passed status if the new branch has no new code compared to the reference branch.

   • Verified that we can change the reference branch in the UI and run the analysis locally, with or without specifying the reference branch in the command. (If we didn’t specify the reference branch, it should take master as RB.)

   • Verified that renaming of the reference branch and using the new name for analysis are working correctly.

   • Verified that when a branch is deleted in the UI and then used as a reference branch in the SFDX command, a 404 error is returned.

   • Verified the version option on activity page by providing name and editing name.

   • Verified the following options that are present under new code period for any branch under specific settings for a branch.

     • Previous version

     • Number of days

     • Specific analysis

     • Reference branch

   • Verified the functionality by adding new code with vulnerabilities and fixed some issues that were marked as false positives in the UI.

   • Verified the sonar scanner command as well for the reference branch.

2. Fixed issue in rule “sf:OptimizeParallelUnitTests” (IsParallel) This rule is designed to ensure that isParallel is present, either True or False. Previously, when a second flag was added to a test, the rule threw a violation, e.g., @IsTest(SomeFlag=True IsParallel=False). This should not throw a violation since IsParallel is specified. Instead, something like @IsTest(SomeFlag=True) should throw a violation, as IsParallel is not specified. This issue was occurring because the rule detection logic was looking for “@isTest(isParallel=true/false)” annotation being defined/set individually on its own (only), but not when used in combination with other annotations. Not being able to detect combination annotations setting was thereby causing false positive violations. Various scenarios tested outcomes for the rule BEFORE the fix was added:

   1. Not setting “@isTest(isParallel=false)” (or true) – Violation – Correct behavior.

   2. Setting @isTest(isParallel=false) or @isTest(isParallel=true) – No violation – Correct behavior.

   3. Setting @isTest(OnInstall=true isParallel=False) – Violation – Incorrect behavior as isParallel is set.

   4. Setting @isTest(SeeAllData=False isParallel=True) – Violation – Incorrect behavior as isParallel is set.

   Results demonstrated that scenarios a and b were working as expected; however, in scenarios c and d, the rule was not able to understand multiple combined annotations format of @IsTest(xxx=false yyy=true) This fix corrects the issue. We have verified the Apex rule sf:OptimizeParallelUnitTests via multiple scenarios, and all are working as expected.

1. Fixed issue in rule for VF “vf:AvoidExternalResources” (in which the rule was checking ALL attributes for external resources, producing false positives). Previously, the rule vf:AvoidExternalResources was checking ALL attributes for external resources, which it should not do. This resulted in false positives being flagged as violations. This fix ensures that the check is limited to the “value” attribute only, to avoid false positives and ensure the rule functions as intended. As an example, the following will NOT be flagged as a violation: <apex:includeScript value="{!$Resource.example_js}" loadOnReady="true"/> //Good: Uses a static resource.

Release Notes 24.0.12

Release Date: 9 October 2024

Summary

CodeScan 24.0.12 is comprised of the following 2 components:

• 1 Rule Enhancement

• 1 Fix

Component details are listed in their corresponding sections within this document.

Enhancements

1. Enhanced the rule sf: {{FieldLevelSecurity}} to eliminate false positives

Summary: Previously, this rule was flagging issues that were actually false positives. This was occurring when an SOQL query has an inner query calling the related Object.

In this enhancement, the Object is checked using isAccessible() before accessing its data.

Per Salesforce, when checking the Access for the inner query object, it allows you to check by using __c, but while making an inner query on related Objects, it must be plural and end with __r.

Further, we added SYSTEM_MODE support to the rule enhancement via a rule parameter (where rules admins can choose true or false to include SYSTEM_MODE).

For additional info on Object permission Checks and SYSTEM_MODE, refer to: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_perms_enforcing.htm|https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_perms_enforcing.htm|smart-link

Fixes

1. Fixed errors when reattaching Bitbucket projects using new enhanced security.

In the previous CodeScan release (24.0.11), we enhanced the security of our Bitbucket webhooks to stay current with the guidelines provided in Bitbucket’s documentation (https://support.atlassian.com/bitbucket-cloud/docs/manage-webhooks/#Secure-webhooks).

We also implemented a process to make this update easier for existing customers using Bitbucket projects.

Some customers were experiencing errors with this process. This fix has corrected those errors in full, and we have validated that the process works as expected.

For more information on reattaching Bitbucket projects, please refer to our Knowledge Base:

https://knowledgebase.autorabit.com/fundamentals/faq/codescan-faqs/codescan-cloud-issues/reattaching-bitbucket-projects

For your convenience, we are also including the documentation from CodeScan release 24.0.11 regarding the enhanced security for Bitbucket projects.

With this enhancement (in 24.0.11), when you create a new Bitbucket project, you must generate a “secret” key and send it to Bitbucket to create a Webhook. In the Webhook endpoint, you should validate the {{X-Hub-Signature}} header value in accordance with Bitbucket guides.

NOTE: We recognize our customers may have existing Bitbucket projects running in their CodeScan org that were created without this enhanced security feature.

To avoid having errors occur in these existing projects, we have intentionally added a retention period for clients to migrate the projects (reattach them).

We have set 31 December 2024 as the deprecation date. This is the final day to perform the migration before these projects will break (at that point, customers will have to reattach their projects using the enhanced security webhook).

Further, to highlight this notification more visibly, customers with existing Bitbucket projects will receive a new type of Organization Notification directly within the CodeScan UI.

To maximize effectiveness (and only deliver this notification when relevant), CodeScan will check if your organization has any Bitbucket projects without these enhanced security settings.

If true, when Org Admins log in, they will receive this *WARNING* message: “You have to reattach the following Bitbucket projects by the end of 2024 to enhance security: project_key_1, project_key_2, project_key_3, etc."

Starting 1 January 2025, you will not be allowed to trigger the analysis for Bitbucket if that project doesn’t have the secret key configured. Further, instead of the WARNING message, an ERROR message will be displayed.

---

Release Notes 24.0.11

Release Date: 25 September 2024

Summary

CodeScan 24.0.11 is comprised of the following 3 components:

• 2 Functional Enhancements

• 1 Security Enhancement

Component details are listed in their corresponding sections within this document.

Functional Enhancements

1. Org Names are no longer restricted to a single word only

Summary: Previously, customers had a restriction limiting Org Names to a single word. With this enhancement, that restriction has been removed.

Valid strings now include names such as:

• "My Organization"

• "Organization-123"

• "My Organization-123"

• "Org 123"

However, there are some restrictions regarding leading spaces, trailing spaces, trailing hyphens, and invalid characters, such as:

• " Organization" (leading space)

• "Organization " (trailing space)

• "Organization-" (trailing hyphen)

• "My Organization-" (trailing hyphen)

• "Org-!Name" (contains an invalid character !)

1. Enhancement of rule “sf:AvoidPublicFields” (reducing false positives on private classes).

The rule sf:AvoidPublicFields identifies when public fields are used and flags them as issues. Two of the three reasons this rule is important are:

• The internal representation is exposed and, thus, cannot be easily changed.

• When the value is changed in an unexpected way (for example nulled), the implementation may not handle it correctly.

But these are not concerns when those public fields are on a private class.

This enhancement adds a private class validation check first and will not flag the two previously mentioned issues if the class is a private class.

Security Enhancement

Enhanced security for Bitbucket webhooks

We have enhanced the security of our Bitbucket webhooks to stay current with the guidelines provided in Bitbucket’s documentation (https://support.atlassian.com/bitbucket-cloud/docs/manage-webhooks/#Secure-webhooks)

With this enhancement, when you create a new Bitbucket project, you must generate a “secret” key and send it to Bitbucket to create a Webhook. In the Webhook endpoint, you should validate the {{X-Hub-Signature}} header value in accordance with Bitbucket guides.

NOTE: We recognize our customers may have existing Bitbucket projects running in their CodeScan org that were created without this enhanced security feature.

To avoid having errors occur in these existing projects, we have intentionally added a retention period for clients to migrate the projects (reattach them).

We have set 31 December 2024 as the deprecation date. This is the final day to perform the migration before these projects will break (at that point, customers will have to reattach their projects using the enhanced security webhook).

Further, to highlight this notification more visibly, customers with existing Bitbucket projects will receive a new type of Organization Notification directly within the CodeScan UI.

To maximize effectiveness (and only deliver this notification when relevant), CodeScan will check if your organization has any Bitbucket projects without these enhanced security settings.

If true, when Org Admins log in, they will receive this *WARNING* message: “You have to reattach the following Bitbucket projects by the end of 2024 to enhance security: project_key_1, project_key_2, project_key_3, etc."

Starting 1 January 2025, you will not be allowed to trigger the analysis for Bitbucket if that project doesn’t have the secret key configured. Further, instead of the WARNING message, an ERROR message will be displayed.

---

Release Notes 24.0.10

Release Date: 28 August 2024

Summary

CodeScan 24.0.10 is comprised of the following components:

• 1 Enhancement

• 2 New Rules

• 6 Fixes

Component details are listed in their corresponding sections within this document.

Enhancements

1. Enhancement to rule “Use the null coalescing operator instead of ternary”

The original aim of this rule is to identify ternary statements and suggest potential use of "??" operator.  Previously, CodeScan was checking for ternary statements only.

This rule was originally developed according to common development practices in Salesforce where most usages of this would be in ternary. However, it can be applied in scenarios involving if-else and return statements. As such, we have adjusted the rule to account for these use cases. With this enhancement, CodeScan suggests where null coalescing could be used instead of an “if” block (recognizing that if a developer is already thinking about shortening their code with ternary, then they are likely considering null coalescing operator as well).

New Rules

1. New Rule for APEX: “IsBlankForNullChecks”

This is a new rule that leverages the built-in {{isBlank}} and {{isNotBlank}} methods instead of the {{!=}} and {{==}} operators to check for null or empty values.

This approach is especially relevant in programming environments and languages where {{IsBlank}} or equivalent methods are provided for more readable, maintainable, and less error-prone code. Using the {{IsBlank}} method for null checks improves code clarity, reduces the likelihood of bugs, and enhances maintainability compared to using the {{!=}} operator. Developers are less likely to encounter unexpected behavior due to differences in how null and empty values are handled. Additionally, built-in methods like {{IsBlank}} are optimized and tested to handle various edge cases, reducing the potential for errors compared to using the {{!=}} operator. It also makes the code easier to read and understand.

2. New Rule for APEX: “Avoid Classes Without Explicit Sharing”

New Rule to Enforce Sharing Rules in Classes

Summary: Enforce security best practices on classes by ensuring that sharing settings ('with sharing', 'without sharing', or 'inherited sharing') are explicitly declared. This prevents accidental data exposure and enhances code maintainability and compliance with security policies.

Fixes

1. Make fields of CustomObject Compatible with SFDX

CodeScan is in the process of updating all of our Salesforce metadata rules to ensure they support both the Salesforce metadata API as well as SFDX formats for the issues they were built to find.

We’ve architected this change because metadata pulled with SFDX has a different structure than metadata pulled with Salesforce’s metadata API. CodeScan can scan these different structures with some additions to the sf-meta suffixes. For this release, we have ensured that the differences are covered within the types of metadata that have these differences (specifically, the Object metadata contains all field metadata when pulled from the metadata API; however, when this is pulled with SFDX, the object and field metadata are separate).

See the following SF article for details of these differences: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm|https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm|smart-link

2. Fixed issue in rule “sf:AvoidSoqlInLoops”

This CodeScan rule was found to have two issues:

• SOQL in the code does not appear to be in a loop, but CodeScan is flagging as a violation.

• A violation message is displayed multiple times for the perceived detected violation.

The root causes of these issues were identified, and the following enhancements were added:

Top of Form

• Added condition to check if the method call matches the Method name; if not, do not flag as a violation

Bottom of Form

Top of Form

• When checking the nested method call, if method name matches, only then it will throw violation.

• Bottom of Form

Top of Form

• Avoid false positives when a recursive call happens without matching the method name

Bottom of Form

3. Fixed issue when attaching a GIT project for a second time after initially canceling the request

CodeScan UI was inaccessible (page greys out) during scenarios where users were attaching Git analysis to a project in CodeScan where those projects previously had an unattached analysis.

Detail: When users would follow this navigation, they would encounter an error:

1. Select a project with an unattached analysis ->

2. Attach analysis ->

3. select Git ->

4. cancel ->

5. select Git again ->

RESULT: Page is grayed out until the page is refreshed.

The root cause of the issue was identified and fixed. Verification the issue is now resolved included:

1. Creating an empty project and subsequently attaching a Git analysis to the project

2. Deleting the project analysis and attaching a new Git analysis

3. Validating attaching analyses with no issues for:

• Salesforce

• GITHUB

• BITBUCKET

• GITLAB

• GIT

• WEBHOOK

4. Fixed issue in rule “sf:FixDuplicateMethods”, where Nested statements were being flagged (which was a false positive issue).

Previously, the sf:FixDuplicateMethods rule was throwing violations for nested statements, which is not the intended behavior. The root cause was identified and fixed, and now the rule is working as designed and expected.

5. Fixed issue with Date Filter on IDE Usage Page

In the 24.0.9 release, we made several UI enhancements to the “IDE Usage” page, including the addition of a date filter for:

• Last 30 days

• Last 60 days

• Last 90 days

• Last 180 days

However, the action “On click” wasn’t showing the filtered list as expected. The root cause was identified and the issue has been remediated. The date filter now works as designed and expected.

6. Fixed issue with Individual / All Filter on IDE Usage Page

In the 24.0.9 release, we made several UI enhancements to the “IDE Usage” page, including the addition of a filter toggle for Individual / All where:

• Upon toggling to “Individual,” the last connection for each individual unique user list is shown.

• Upon toggling to “All," the full list of activity is shown (every connection for the selected duration).

However, the action “On click” wasn’t showing the filtered list as expected. The root cause was identified, and the issue has been remediated. The date filter now works as designed and expected.

---

Release Notes 24.0.9

7 August 2024

The latest CodeScan release is comprised of the following components:

• Enhancements

• New Rule

• Fix

Enhancements

1. Feature Enhances the “sf.testfile” parameter in project settings UI Summary: Previously, customers using our Git integration could store their test coverage in their repository branches by using a parameter called sf.testfile, which allows you to add coverage to your code with SFDX JSON outputs. With this enhancement, CodeScan allows the parameter to be configurable at a project level. Adding this parameter will allow teams to view the coverage on the CodeScan dashboard. The addition of this parameter notably provides more value for SFDX workflows. Further details are available at the following link: Importing Code Coverage from SFDX Projects.

2. UI Enhancements to the IDE Usage Page Summary: The “IDE Usage” page has been updated with the following UI components:

For the IDE Type, logos are now shown instead of text Added a date filter, including: Last 30 days Last 60 days Last 90 days Last 180 days Updated the Column title of “Use at” to “Time Stamp.“ Added a filter toggle for Individual / All as shown. Upon toggling to “Individual,” the last connection for each unique user list is shown. Upon toggling to “All," the full list of activity—every connection for the selected duration—is shown.

1. New “Exception” status for Security Hotspots Summary: For this release, the “Exception” status essentially mirrors the functionality of the “Acknowledged” status; but this is just temporary. We will be adding the ability to assign a “date time stamp” to this feature, which will then allow the issue to be flagged after the expiration of the date time stamp.

New Rule

New Rule for “Cognitive Complexity” in CodeScan

This is a new rule for assessing Cognitive Complexity. Note that we had a previous Cognitive Complexity rule. What’s different is that this rule aims to enhance the understanding of code readability and maintainability by identifying areas where the cognitive load on developers may be high.

To introduce this new rule for assessing Cognitive Complexity, we pinpointed specific code structures and circumstances that contribute to increased cognitive load. This enables developers to refactor complex sections of code, leading to improved code quality, readability, and maintainability.

Basic criteria and methodology: A Cognitive Complexity score is assessed according to three basic rules:

• Ignore structures that allow multiple statements to be readably shorthanded into one. Increment (add one) for each break in the linear flow of the code.

• Increment when flow-breaking structures are nested.

• Additionally, a complexity score is made up of four different types of increments:

  • Nesting – Assessed for nesting control flow structures inside each other

  • Structural – Assessed on control flow structures that are subject to a nesting increment and that increase the nesting count.

  • Fundamental – Assessed on statements not subject to a nesting increment.

  • Hybrid – Assessed on control flow structures that are not subject to a nesting increment but increase the nesting count.