Release Notes 24.0
Newest CodeScan Releases
CodeScan Cloud
Release Notes 24.0.13
Release Date: 30 October 2024
Summary
CodeScan 24.0.13 is comprised of the following 4 components:
Component details are listed in their corresponding sections within this document.
New Features
There are no new features associated with this release.
Enhancement
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
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.
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:
Not setting “@isTest(isParallel=false)” (or true) – Violation – Correct behavior.
Setting @isTest(isParallel=false) or @isTest(isParallel=true) – No violation – Correct behavior.
Setting @isTest(OnInstall=true isParallel=False) – Violation – Incorrect behavior as isParallel is set.
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.
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
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
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:
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
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 !)
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:
Select a project with an unattached analysis ->
Attach analysis ->
select Git ->
cancel ->
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:
Creating an empty project and subsequently attaching a Git analysis to the project
Deleting the project analysis and attaching a new Git analysis
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
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.
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.
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.
Fix
Fixed intermittent “400 bad request error” experienced by some users after successfully logging in via SSO. This issue is now resolved. We have verified that users who have been assigned to an organization and have since converted to SSO are able to log in to the application successfully.
Release Notes 24.0.8
Release Date: 10 July 2024
New Features
This update includes several New Features within CodeScan’s Visual Studio Code IDE Extension:
New CodeScan Issue Filter: Quickly sort and filter issues by type and severity for efficient code review.
Fixed a plugin issue that failed to recognize CodeScan-specific JavaScript (JS) and VisualForce (VF) rules.
Resolved duplicate issue detection for specific Apex rules.
Added automatic token generation and connection flow UI.
Added support for SonarQube 9.9 and later versions.
Enhancements
Rule Enhancement for “Avoid Using Test.isRunningTest()” {APEX Rule}: Summary: Previously, this rule was flagging violations when finding methods written as Test.isRunningTest(). This rule has been enhanced to also flag violations when finding methods written as System.Test.isRunningTest().
Decrease False Positives reported for Rule “sf:FixDuplicateMethods” Summary: CodeScan recognizes that methods should not share the same implementations. As such, the scope of the rule will be limited to methods with actual implementations, rather than including interface method declarations. This means the rule will now focus solely on detecting and addressing duplicate implementations within concrete classes, ensuring that only methods containing executable code are evaluated. Violations reported by this rule will now include details of all duplicate methods affected. This means each violation will list every instance of a method that shares the same implementation, making it easier to identify and resolve duplicated code. These updates will make the rule more precise, and its violation reports more comprehensive, enhancing its effectiveness.
Enhancement to Rule: "Field-Level Security" (FLS) CodeScan’s FLS rule did not detect DML methods called when syntax is insert (record), update (record), etc. Instead, FLS was only detecting when “insert record;” syntax was used. We made a parser update within CodeScan and an enhancement to the rule was applied, which corrected the syntax detection.
Enhancement to Rule: "Cyclomatic Complexity" Summary: Several enhancements were applied to the rule cyclomatic complexity, including adding the decision points '?', '&&', '||', and 'catch'.
Added dashboard Url to Job status API Summary: On the Project Analysis page, we have added dashboard Url to Job status API on success/failure of analysis:
Fixes
UI Improvement on Rule “NullCoalescing operator” We completed an alignment adjustment within the CodeScan UI for this specific rule. Previous UI:
Adjusted UI:
UI Improvement on Rule “Lightning channel Exposed” We completed an alignment adjustment within the CodeScan UI for this specific rule. Previous UI:
Adjusted UI:
Improved IDE Usage Tracking Previously, the IDE tracking page was tracking every use of a token by a user and displaying it on this page. The updated functionality is: 1 entry per user, where the tracking page gets updated / refreshed when a user token is used within VS Code. NOTE: Only VS Code updates on the page. Additionally, instead of login ID, we now display the name of the user and the email under a single column called ‘User’. Also, we changed the title to IDE Usage instead of “IDE Usages” * Finally, we removed the token information, as it is not needed.
Fixed CodeScan IntelliJ Plugin error Previously, the CodeScan IntelliJ Plugin was throwing an error during binding updates when connected to SonarQube 10. The issue was caused by self-hosted connections being incorrectly detected as cloud connections, resulting in an error popup. This issue occurred when connecting to self-hosted SQ 10.x versions in both 2023 and 2024-based IntelliJ versions. The issue error message (popup) resulted from an API call failure. This issue has now been remedied with this fix.
Generated SARIF now associated with the branch being scanned Previously when SARIF was generated while scanning from our SFDX plugin, the SARIF was generated from the main branch of the project and NOT the branch being scanned. This has been corrected, and now the SARIF is generated from the branch of the project that has just been scanned.
CodeScan Polyfill Protection Release
Release Date: 6 July 2024
We are excited to announce that CodeScan has been updated with crucial enhancements to address recent security concerns related to polyfills. Recent advisories have highlighted significant threats stemming from polyfills, particularly those distributed via the CDN polyfill.io, which are linked to malware.
This update, effective July 6th, introduces advanced protection mechanisms to ensure your Salesforce environment remains secure.
Here’s how CodeScan is advancing your security:
Configuration Scanning: Our enhanced system now scans the configuration settings of Salesforce components, including Salesforce Sites, Salesforce CORS (Cross-Origin Resource Sharing), and Salesforce CSP (Content Security Policy), to detect any unauthorized calls to polyfill.io domains.
Component Scanning: We are scanning the core Salesforce components that enable developers to build sophisticated, custom user interfaces including Visualforce, Aura, Lightning, and other web components
Package Scanning: Our updated scanning mechanism checks downloaded packages from Salesforce AppExchange to ensure they do not contain insecure calls to polyfill.io domains
Why This Matters
Recent security advisories highlight the risks associated with compromised polyfills.
What Do I Need to Do?
For our SaaS Cloud clients, these updates were included in the most recent maintenance release on July 06, so no action is required on your side. For our On Prem clients, these rules will be included in the 24.0.8 On Prem release, which is scheduled for July 17. For our Dedicated Cloud clients, please contact your Account Team to schedule your upgrade.
Release Notes 24.0.7
Release Date: 19 June 2024
Rule Updates
The 'Hard Coded Credentials' rule name has been changed to 'Use Named Credentials' for clarity.
'Use Named Credentials' and 'Field Level Security' rules have updated descriptions highlighting Salesforce best practices and better paths to resolution.
Bug Fixes
Fixed a false positive in the rule 'Avoid using methods getDescribe and getMap inside Loops' when using custom methods with similar names.
A link was fixed on the rule description pages.
Filtering the list by project, the rule now works correctly.
New code settings no longer switch depending on the main branch of the project; all branches can be configured independently. A warning will be shown if the setting chosen will have no effect.
Release Notes 24.0.6
Release Date: 5 June 2024
Summary:
CodeScan 24.0.6 is comprised of the following 3 enhancements:
SBOM Upgrade for ADO extension:
CodeScan currently provides an ADO extension to integrate with Azure DevOps. For this enhancement, we have upgraded components and libraries (within our SBOM), eliminating all high-severity vulnerabilities.
Severity added to SARIF output:
CodeScan currently generates SARIF output; however, that SARIF output in GitHub does not contain the severity. By adding severity to our SARIF output, CodeScan can now provide a more verbose presentation of the issues in GitHub. This change will provide a better experience for our customers working in GitHub Actions.
Added more fields in our Report Header:
CodeScan report header contained limited information regarding the context of the report. This enhancement provides much more detailed information including:
Field 1
Label = "Report Generation Date"
Value = Date report was created
Field 2
Label = “Project Name”
Value = Name of project
Field 3
Label = “Main Branch”
Value = Name of the main branch
Field 4
Label = “Main Branch – Last Analysis Date”
Value = Date of the last analysis of the main branch
Field 5
Label = “Comparison Branch”
Value = Name of the comparison branch or pull request branch
NOTE: If there is not a corresponding comparison branch or pull request branch, the value should be “Not Applicable.”
Field 6
Label = “Comparison Branch – Last Analysis Date”
Value = Date of the last analysis of the comparison branch
NOTE: If there is not a corresponding comparison branch or pull request branch, the value should be “Not Applicable.”
Field 7
Label = “Version”
Value = The corresponding version number listed in version history / measure history
Changelogs
27 June 2024
v. 2.0.3
Changes were required to support fixes and enhancements of the VS Code CodeScan Plugin (v2.0.3) to VS Code Extension Marketplace; specifically, we fixed a plugin issue that caused non-recognition of CodeScan-specific JS and VF rules. Support ticket #114684
13 June 2024
v. 2.0.2
New CodeScan Issue Filter: Quickly sort and filter issues by type and severity for efficient code review. You can click on the specific Type or Severity to only see issues of that type.
The released plugin can be updated directly from VSCode and also can be found in this link: https://marketplace.visualstudio.com/items?itemName=codescansf.codescan-vscode
Release Notes 24.0.5
Release Date: 15 May 2024
New Rules
Rule Name: “Comment All Hardcoded Values” Category: New APEX rule in CodeScan Purpose: Ensure comments are included when using hardcoded values in Apex classes Detail: Ensures any hard-coded values or strings in the code are accompanied by descriptive comments or, alternatively, use constants. This practice enhances code readability, maintainability, and will make it easier for other developers to understand the purpose of these values.
Rule Name: “Use the null coalescing operator instead of the ternary operator” Category: New APEX rule in CodeScan Purpose: CodeScan recommendation to consider replacing ternary operators (? :) for explicit null checks with the Null Coalescing operator (??) where applicable to enhance code performance and clarity. Detail: In Salesforce's Spring '24 release, the null-coalescing operator has been introduced in Apex. This rule will identify where this operator could be used but isn’t being utilized. For further information, please refer to Salesforce Release Documentation - Null Coalescing Operator.
Rule Name: “Use Accessibility Attributes” Category: New Lightning Web Component Rule in CodeScan Purpose: Updating LWCs with certain attributes makes these components more accessible to users of assistive technology. Detail: Accessibility software such as screen readers interpret the elements on a webpage using the title attribute, so specifying a value for components is very important. Salesforce’s ARIA attributes allow accessibility software to gather more information on the state of the page and align with the ARIA standard. For further information, please refer to: Component Accessibility Attributes Accessible Rich Internet Applications (WAI-ARIA)
Rule Name: “nCino Inactive Workflow Rules” Category: New nCino Gold Standard Rule in CodeScan Purpose: Removing inactive, unmanaged workflow rules in a Salesforce instance allows organizations to maintain an organized workflow environment Detail: Removing inactive UNMANAGED workflow rules will streamline workflow processes, reduce confusion among users, and improve system performance. This action leads to a cleaner and more efficient Salesforce instance. Further, removing inactive UNMANAGED workflow rules helps declutter the Salesforce environment, making it easier for administrators and users to navigate and manage active workflows effectively.
Rule Name: “Avoid JavaScript Scriptlets in Aura Components and Apex Pages” Category: New Aura / Lightning / Visualforce Rule in CodeScan Purpose/Detail: JavaScript scriptlets should not be directly embedded within the markup of Aura components or Apex pages. Instead, utilize Salesforce Static resources for including JavaScript code. Using direct <script> tags in components or pages can pose a security risk, increasing the likelihood of cross-site scripting (XSS) attacks. For further information, please refer to: https://developer.salesforce.com/blogs/2023/08/the-top-20-vulnerabilities-found-in-the-appexchange-security-review - The Top 20 Vulnerabilities Found in the AppExchange Security Review MITRE, CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Rule Name: “Exposed Lightning Message Channel” Category: New LWC / Aura / Visualforce rule in CodeScan Purpose: It is recommended to verify instances where the 'isExposed' flag in Lightning Message Channels is set to true. Setting this flag can lead to unintended access to the Lightning Message Service (LMS) API, potentially resulting in unauthorized message publishing and subscribing across components within the Salesforce ecosystem. Detail: This term specifically refers to cases where you have not configured the 'isExposed' flag in Lightning Message Channel to false. Since this provides access to the Lightning Message Service (LMS) API, which lets you publish and subscribe to messages across the DOM and between Aura, Visualforce, and Lightning Web Components, it should be set to false. For further information, please refer to: https://developer.salesforce.com/blogs/2023/08/the-top-20-vulnerabilities-found-in-the-appexchange-security-review
Rule Name: “Utilizing Apex Unit Tests with @IsTest(IsParallel)” Category: New APEX rule in CodeScan Purpose: The annotation “@isTest(isParallel=true/false)” can be set in Apex test classes to indicate whether the particular test can be executed parallelly or sequentially (performance enhancement). Detail: When writing Apex unit tests, ensure that the @IsTest(IsParallel) annotation is set, whether true or false. This keeps the option of running tests in parallel visible through development to optimize test execution times. However, it should only be enabled in scenarios where it adds value without introducing risks or conflicts. Further information: When utilizing Apex unit tests with the annotation @IsTest(IsParallel=true), it's essential to be aware of potential drawbacks to ensure smooth execution and accurate results. Enabling parallel testing with @IsTest(IsParallel=true) may lead to UNABLE_TO_LOCK_ROW errors due to resource competition, which in turn can result in rerunning failed tests in serial mode. Additionally, it's important to note that this setting does not affect change set deployment or package upload processes. By understanding these drawbacks, developers can effectively manage test execution and deployment processes, minimizing errors, and ensuring the reliability of test results.
Fixes
Updated the rule “Avoid duplicate conditions in "if"/"else if" and "switch" statements to eliminate dead code." Detail: In the Initial implementation, the "if/else-if" statements and the nested "if/else-if" statements present within them were not allowed to have duplicate conditions. Now only the related "if/else-if" statements are checked for duplicate conditions, without considering the nested "if/else-if" statements present within them. Value: The same conditions can cause duplication and lead to dead code in statements such as "if"/"else if" and "switch." This issue often occurs due to a copy/paste error. In the best-case scenario, it results in dead code that serves no purpose, but in the worst-case scenario, it introduces bugs that may propagate as the code is maintained, potentially leading to unexpected behavior.
Updated the documentation and example on rule “API Version is Too Old” to: “This rule identifies visual force pages which are using older versions of the API. Change the API Version of this visual force page.” Reason for change: The description and example needed to be updated for the rule.
Release Notes 24.0.4
Release Date: 21 April 2024
New Features
In this release, we've added more metadata suffixes as recognized types for Salesforce metadata:
Newly added CodeScan logic:
Any suffix with .[dot] present will be treated as a correct suffix and not be modified. This means:
.field-meta.xml - will treat all files ending with .field-meta.xml as metafiles.
-meta.xml - will treat all files ending with -meta.xml as metafiles.
.xml - will treat all files with .xml suffix as metafiles.
xml - will treat all files with .xml suffix as metafiles. (.[dot] is added at the start if not provided)
IDE Enhancements
Add UI element within the CodeScan Administration tab to list IDE license usage at the Org level.
Admins are now notified within the UI when IDE licenses have exceeded the maximum allotment.
Users are now notified in IDE when additional IDE licenses are required (i.e., the company has allocated all available licenses).
CodeScan now removes IDE usage records for users who have been removed from their organization’s member group.
Fixes
Improved the CodeScan parser as it relates to Visual Force. Specifically, the parser had some issues recognizing parts of Aura code (for example, with components (cmp), the parser was unable to recognize divs and spans across multiple lines). With this release, we have corrected these issues and verified that the Visual Force parser for .cmp, vf, xml, and .page files are all parsed properly. Further, CodeScan users can successfully see these issues after analysis.
Fixed a NullPointerException with the Apex rule “Null Coalescing Operator.”
Fixed an issue with New Code settings. Customers who were changing new code settings while selecting the reference branch as “main” were receiving a notification that the settings had been saved. However, the change was not reflected/applied properly to the CodeScan engine. This issue is now resolved.
Release Notes 24.0.3
Release Date: 27 March 2024
This release has several new features that support enhanced user capabilities.
CSV Export: With this fix, we added a URL column to the CSV Export that enables teams to quickly navigate to the Issue and get a fix in place.
CSV Export not exporting all issues: To avoid doubling up the queries, when a user presses the Export button, the Export and Reset buttons are grayed out and unusable. After the buttons are clicked, the following message should show underneath: "Please remain on this page while your report is generated. Depending on the number of issues in your report, this may take up to 5 minutes. Your download will start shortly."
CSV Export added functionality – Pull Requests: This enables CSV Exports to include the options to filter and group code issues by specific pull request(s).
Quality Profile error: A bug that caused project analysis issues is now fixed in the sfmeta:FlowNullHandler rule.
NullPointerException in IdempotentBinaryOperatorsRule: This fixes an exception when a null pointer is thrown in IdempotentBinaryOperatorRule.txt.
Quick Report — Issue Counts: This fixes a bug causing issue count errors in Quick Report.
Null Pointer Exception — Apex classes: This fixes an error causing an exception during analysis of Apex classes.
Null Pointer Exception for IfElseDefaultCase Rule: This fixes a null pointer exception thrown for triggers.
False Positives: This fixes false positive errors for the sf:FixDuplicateConditions rule. The same conditions can cause duplication and lead to dead code in statements such as "if"/"else if" and "switch". This issue often occurs due to a copy/paste error. In the best-case scenario, it results in dead code that serves no purpose, while in the worst-case scenario, it introduces bugs that may propagate as the code is maintained, potentially leading to unexpected behavior. Addressing false positives for cases such as:
Use Relative, not Absolute URLs: Code that uses absolute URLs for Salesforce pages will only work when running on the corresponding Salesforce instances. This can cause code to fail when deployed in another sandbox or production environment. Use relative URLs to avoid this issue.
Null Pointer Exception – sf:AvoidAbsoluteURL rule: Fixed a null pointer exception during analysis associated with the sf:AvoidAbsoluteURL rule.
Release Notes 24.0.2
March 2024
This update introduces several new rules and bug fixes for current rules. This includes:
Apex Rules:
Duplicate method implementations: Methods should not share the same implementations. To prevent duplication and confusion, avoid using two methods with identical implementations.
Code length: Lines should not be too long in APEX. Limiting the length of code lines enhances code clarity and readability by reducing complexity and improving quick understanding.
System.runAs to test user permissions: To ensure accurate and realistic testing of user permissions, it is crucial to utilize System.runAs during test execution, ensuring logic is tested in the same context in which it will run.
Relative Salesforce URLs: Salesforce pages should use relative URLs, as code using absolute URLs for Salesforce pages will break in different environments.
“If ... else if” should have “else” case: Include a default case using an "else" statement at the end of "if" and "else if" clauses to handle all conditions and provide code clarity.
Limit case clauses in switch statements: Using a large number of case clauses in switch statements creates complex, difficult-to-read code.
Avoid Identical Expressions on Both Sides of a Binary Operator: When both sides of a binary operator have identical values, the condition will always give the same result.
Avoid Sending Emails in Loops: Avoid using Messaging.sendEmail within loops to prevent exceeding Salesforce governor limits and to enhance application performance.
Avoid duplicate conditions in "if"/"else if" and "switch": When the same conditions are used in statements like "if"/"else if" and "switch", it can lead to duplicate or dead code.
API Versions 7.0 through 20.0 Retirement: The retirement of older Salesforce Platform API versions (7.0 through 20.0) after the Summer '22 release is a critical step to ensure the continued smooth operation of Salesforce applications.
Avoid using methods getDescribe and getMap inside Loops: The ‘getDescribe’ and ‘getMap’ methods typically involve fetching metadata information for objects and fields. Invoking them inside loops can result in unnecessary overhead.
Assertion Rules:
Use Assert.areEqual instead of Assert.isTrue: This rule detects Unit test assertions in object references equality. Instead of using Assert.isTrue as an equality check, these assertions should be made by more specific methods, like Assert.areEqual.
Use Assert.isTrue instead of Assert.areEqual: When asserting a value that is the same as a Boolean literal, use Assert.isTrue, instead of Assert.areEqual.
Use Assert Equals Instead of Boolean Equality Assertion: This rule detects unit test assertions in object references equality. Instead of using Assert.isTrue combined with "==" as an equality operator, these assertions should be made by more specific methods, like Assert.areEqual (expected, actual).
Unit Assertions should include a Message: Unit assertions should include a message. In other words, use the three-argument version of Assert.areEquals(), not the two-argument version.
Unit Test Method Contains Too Many Asserts: Unit tests should not contain too many asserts. Many asserts are indicative of a complex test, for which it is harder to verify correctness. Consider breaking the test scenario into multiple, shorter test scenarios. Customize the maximum number of assertions used by this Rule to suit your needs.
Non-Unit Test Methods Should Not Contain Asserts: Asserts should only be used in test methods.
Misuse of Assert Class: Assert Class can be misused if not applied correctly. To ensure the correctness of our code and avoid common pitfalls, establish best practices for its usage.
Use Messages in Assert Statements: Ensure that messages are included when using the assert method with the message parameter to improve code quality and make it easier to identify the cause of failures during testing and debugging.
Consider Using Assert in place of System.Assert: This new class aims to enhance the readability and maintainability of test code for developers. It is preferable to use Assert in your tests instead of older System.Assert methods.
LWC Rules:
Enable Salesforce Lightning Web Security (LWS): Enabling LWS ensures that the Lightning components within our Salesforce instance are executed in a secure and controlled environment, reducing the risk of potential security vulnerabilities.
SF Meta:
Adopt the ICU Locale Formats instead of JDK locale formats: Salesforce is retiring the JDK locale formats with the Spring ’24 release. ICU is the new standard enforced in API version 45. Make sure your custom code does not use JDK locale formats and instead uses locale-neutral methods.
Set Flows to Auto Layout: Implementing auto-layout for your flows helps designers modify layouts more quickly, allowing them to iterate on their designs with greater speed. It ensures elements are perfectly aligned and evenly spaced, improving readability in complex Flows.
Potential Overuse of Rollup Summaries: Ensure compliance with Salesforce's limit of 25 roll-up summary fields per object to prevent potential issues arising from exceeding Salesforce platform limits.
Bug Fixes:
Improvement was provided on how to fix for the "Deserializing JSON is Security Sensitive" rule.
We provided a fix on the "sf:AvoidUsingHardCodedId" rule not detecting hard-coded IDs as expected.
Wrongly identified violations in specific scenarios were fixed for the "Comments are Required" rule.
The rule "sf:AvoidPublicFields" was updated to exclude public fields with the
@InvocableVariable
annotation.We provided a fix for the rule's missing root element in "RuleSet."
We provided a fix for the "Consider removing inactive flows" rule not working correctly.
Release Notes 24.0.1 Feb 2024
The following items were implemented, fixed, or enhanced with this release:
We fixed a parser issue in the "Avoid Untrusted/Unescaped Variables in DML Query" rule.
A new rule parameter,
allowList
, was added to the "Track Usage of @SuppressWarnings" rule.We fixed the "Get help" action, which was not working when users clicked the plus (+) icon.
Security tokens are now sorted by creation date.
A fix was provided for the "Flows API Version Is Too Old" rule to prevent Null Pointer Exceptions.
Last updated