Cloud Release Notes 25.1
CodeScan Cloud Release Notes
Integration Requirements for CodeScan v25.1.0+
Please note that there are updated requirements for customers who are using one or more of the following to integrate with CodeScan:
SFDX
SonarScanner
ADO
VS Code
IntelliJ
Please refer to our integration requirements page for further details.
CodeScan Release 25.1.15
Release Date: 30 November 2025
Summary
CodeScan 25.1.15 is comprised of the following 4 components:
1 Rule Enhancement
3 Fixes
Component details are listed in their corresponding sections within this document.
Rule Enhancements
1. Enhanced the logic in the CodeScan rule “Unnecessary Boolean Assertion”
{Rule ID: sf:UnnecessaryBooleanAssertion}
Several customers have reported that the current rule detects unnecessary Boolean assertions only when using the System.assert() method.
However, it does not flag similar patterns when assertions are made through the Assert class methods such as Assert.isTrue(true) or Assert.isFalse(false).
To improve coverage, we enhanced the rule logic to include these Assert class scenarios, ensuring consistency across both assertion types.
Fix Summary
Extended the rule logic to detect unnecessary boolean assertions in the following cases:
Assert.isTrue(true)
Assert.isFalse(false)
Updated the rule message and description to clearly explain why these patterns are redundant.
Updated Rule Description:
A Unit test assertion with a Boolean literal is unnecessary since it always will evaluate to the same thing. Consider using flow control (in case of assertTrue(false) or similar) or simply removing statements like System.assert(true) and Assert.isFalse(false). If you just want a test to halt after finding an error, use the System.assert(false, 'message') or Assert.isFalse(false, 'message') methods and provide an indication message of why it did.
Verified the following scenarios are working as expected:
Noncompliant scenarios using System.assert(true), Assert.isTrue(true), and Assert.isFalse(false). All were correctly flagged as expected.
Compliant scenarios have been tested. (by using only string values).
Fixes
1. Fixed an issue in the rule “Require CSRF Protection On GET Requests”
{Rule ID: vf:RequireConfirmationToken}
During our routine, internal rule evaluation process, we discovered that this rule wasn’t firing as expected. As such, we overhauled the rule logic to address this issue.
Summary:
The current xpath for this rule is:
//Document//Element[@Name='confirmationtokenrequired'][Text[@Image='false']]
We recognize that this will not work as expected, as the confirmation token is actually in the metadata of the page and the tag is in camel-case (confirmationTokenRequired).
The logic was updated to:
//Document//Element[lower-case(@Name)='confirmationtokenrequired'][Text[@Image='false']]
With this enhancement, the rule will:
find the correct tag
look in the page-meta.xml metadata file (not the page itself)
Verified the following scenarios and confirmed that the updated rule logic is working as expected.
“vf:RequireConfirmationToken” getting triggered only when the corresponding meta.xml has false for ConfirmationToken tag .
Verified the rule behavior using by uploading only page file and then with corresponding meta.xml file with true and meta.xml file with false.
2. Fixed an issue in the rule “Switch statements should not have too many case clauses”
{Rule ID: sf:MaximumNumberOfCase }
Some customers have reported that this rule throws out of bounds exceptions. Upon investigation, we determined that this is caused by an empty switch statement, which manifests as a parser error when this class is added in Salesforce.
The aim of fix is to make sure that the CodeScan parser sees empty switch statements as syntax errors.
Verified that the below scenarios are working as expected.
Verified that the rule does not throw out of bounds exceptions in the analysis logs (it should not throw this and, as such, has been validated as working as expected).
Verified “sf:MaximumNumberOfCase” rule is triggered only when the maximum limit is exceeded.
3. Fixed an issue in the CodeScan UI on the “Quality Gate Changelog” page, where the “author name” field overlaps with the “action taken” field.
Some customers reported an issue in the CodeScan UI on the “Quality Gate Changelog” page, where the “author name” field overlaps with the “action taken” field.
This fix remediates that issue in full.
Verified the below scenarios and validated that the fix is working as expected.
Verified that the “author name” filed does not overlap with the “action taken” field.
Verified with different actions (Updated, Activated, Deactivated).
CodeScan Release 25.1.14
Release Date: 16 November 2025
Summary
CodeScan 25.1.14 is comprised of the following 10 components:
1 New Feature
3 Rule Enhancements
2 Rule Deprecations
4 Fixes
Component details are listed in their corresponding sections within this document.
New Features
1. New rules to Identify Potential Sensitive Data /PII Fields
Description
These rules identify potential sensitive data and Personally Identifiable Information (PII) fields within the Salesforce Apex code. This helps organizations ensure these fields are handled securely and comply with data privacy regulations.
Hypothesis:
By implementing these rules to identify potential sensitive PII fields, CodeScan can identify and address security risks associated with handling sensitive PII data in Salesforce.
CodeScan Sensitive Data Scanning uses regular expression patterns to search for potential sensitive PII field names. It looks for common identifiers listed below and some custom objects/fields such as "name," "social_security_number," "credit_card," or "passport" and determines if they are being assigned string literals or used in an insecure way (exposed in debug).
Object
Fields Likely to Contain PII
Contact
Birthdate, Department, Email, Fax, FirstName, HomePhone, LastName, MailingAddress, MiddleName, MobilePhone, Name, OtherAddress, OtherPhone, Phone, PhotoUrl, Title
Lead
Address, Company, Email, Fax, FirstName, Industry, LastName, MiddleName, MobilePhone, Name, Phone, PhotoUrl, Title, Website
User
Address, CompanyName, Department, Email, Fax, FederationIdentifier, FirstName, FullPhotoUrl, LastName, MiddleName, MobilePhone, Name, Phone, Title, Username
Account (Business)
BillingAddress, Fax, Name, Phone, PhotoUrl, ShippingAddress
Account (Person Account Fields)
FirstName, LastName, MiddleName, PersonBirthDate, PersonEmail, PersonHomePhone, PersonMailingAddress, PersonMobilePhone, PersonOtherPhone, PersonTitle
NOTE: We implemented advanced logic to Ignore Violations on Dummy/Masked data as shown below:
Data Type
Original/Real PII (Violation)
Dummy/Masked Data (Compliant)
Phone
9876543210
5551234567 or 0000000000
SSN
123-45-6789
000-00-0000 or null
Credit Card
4111111111111234
4111111111111111 (Visa test number)
Address
123 Main Street, New York
123 Test Street, Test City
Value/Purpose:
The purpose of this user story is to enhance data privacy and security within our Salesforce organization. By identifying potential sensitive PII fields, we can Improve data governance and minimize the chances of data breaches.
Acceptance Criteria
Name: Identify Potential Sensitive PII Fields Key: SecurePIIFields Description: Certain standard Salesforce objects (such as Contact, Lead, User, Account, Person Account, and Opportunity) contain fields that may hold PII, including names, addresses, phone numbers, emails, birthdates, and other identifiers. These fields must be treated as sensitive data and protected in compliance with privacy and security regulations (e.g., GDPR, CCPA, HIPAA).
Ensure these fields are handled securely through encryption, masking, and strict access controls to minimize the risk of data exposure or breaches. Type: Vulnerability Severity: Major Message: Potential sensitive PII field detected. Ensure that this field is handled securely. Tags: Security Parameters: Name: sensitiveFields Description: A comma-separated list of sensitive custom fields. Add any custom fields you would like to monitor with this rule.
Verified that sf:SecurePIIFields rules are being triggered in following scenarios:
Verified the sf:SecurePIIFields rules by activating these rules in a specified Quality Profile. The Project analysis should trigger the violation (Security Hotspot).
Verified by giving custom parameters (ssn, credit_card, passport) and validated that they are working as expected.
Verified by sending both string and integer value for credit_card.
Rule Enhancements
1. Enhanced God Class Rule by adding parameters {Rule ID: sf:GodClass}
The sf:GodClass rule currently uses fixed threshold values to identify “God Class” design flaws:
WMC (Weighted Methods Count): > 47
ATFD (Access to Foreign Data): > 5
TCC (Tight Class Cohesion): < 1/3 (33%)
These thresholds are hard-coded and not configurable. We decided to introduce parameters to allow users to customize these values based on their project requirements. By making these thresholds configurable, users can fine-tune the rule according to their project’s code complexity and quality standards, reducing false positives and improving detection accuracy.
Value / Purpose:
Enables users to adjust thresholds to better match their codebase.
Improves usability and flexibility of the rule.
Increases adoption by making the rule adaptable to various team standards.Bottom of Form
Verified the sf:GodClass by validating that users are able to see the violations as expected for the below scenarios
When users provide the below Threshold values:
wmc=47, atfd=5, tcc=0.33 Result: Violation
wmc=10, atfd=5, tcc=0.50 Result: Violation
wmc=60, atfd=10, tcc=0.90 Result: Violation
wmc=30, atfd=2, tcc=0.8 Result: Violation
wmc=100, atfd=10, tcc=0.2 Result: No violation
wmc=9999, atfd=9999, tcc=0 Result: No violation
wmc=0, atfd=0, tcc=0 Result: No violation
wmc=0, atfd=0, tcc=1 Result: Everything violates
2. Updated the Rule Description and Example for rule “Check for Lightning Migration Issues for Salesforce.com and Force.com Links” {Rule ID: vf:LightningAvoidHardcodedSalesforceDomain}
This rule was updated with this new description and example:
“URL references may not work as expected in Lightning Experience or if you decide to swap to My Domain. If you decide to use My Domain, you have to replace hard-coded references to your original URL with references to your new domain. Using something like {!Site.BaseUrl} will avoid this hassle.
See: Considerations Before Transitioning to Lightning Experience”
Example:
Verified these rule updated by confirming that users are able to see the updated description and the example.
3. Updated the Rule Description for rule "em" Tags Should Be Used Instead of "i" {Rule ID: vf:ItalicTagsCheck}
We recognized that this description was out of date and determined it needed to change to: “The <strong>/<b> and <em>/<i> tags have exactly the same effect in most web browsers, but there is a fundamental difference between them: <strong> and <em> have a semantic meaning, whereas <b> and <i> only convey styling information like CSS.
When <b> can have simply no effect on a device with limited display or when a screen reader software is used by a visually impaired person, <strong> will:
Underline the characters on a phone or tablet
Speak with lower tone when using a screen reader
Display the text as bold in normal browsers
Consequently:
In order to convey semantics, the <b> and <i> tags shall never be used,
In order to convey styling information, the <b> and <i> should be avoided and CSS should be used instead.
Verified the rule description and confirmed that the updated description which is displayed as expected.
Rule Deprecations
1. Deprecation of 2 rules for “disallow irregular whitespace outside of strings and comments” (one for Visualforce and one for JavaScript) {Rule ID: cs-vf:no-irregular-whitespace and Rule ID: cs-js:no-irregular-whitespace}
The reason these rules are being deprecated is because they do not fire before the parser catches the issue. These types of irregular white space are no longer even seen as parsing JavaScript.
Further, we have updated the descriptions for these rules to include: “This rule has been deprecated due to these types of white space being caught by the JavaScript parser before a rule can be fired. Please make sure you have the cs-js:exception rule in your javascript Quality Profile to be made aware of these errors.”
Verified the Rule Deprecations of cs-vf:no-irregular-whitespace and cs-js:no-irregular-whitespace and confirmed users are able to see the updated status as Deprecated and the updated description for these rules.
2. Deprecation of 2 rules for “disallow octal escape sequences in string literals” (one for Visualforce and one for JavaScript) {Rule ID: cs-vf:no-octal-escape and Rule ID: cs-js:no-octal-escape}
The reason these rules are being deprecated is because they do not fire before the parser catches the issue. These types of octal escapes are no longer even seen as parsing JavaScript.
Further, we have updated the descriptions for these rules to include:
“This rule has been deprecated due to these types of octal escapes being caught by the JavaScript parser before a rule can be fired. Please make sure you have the cs-js:exception rule in your javascript Quality Profile to be made aware of these errors.”
Verified the Rule Deprecation for cs-vf:no-octal-escape and cs-js:no-octal-escape and confirmed users are able to see the updated status as Deprecated and the updated description for these rules.
Fixes
1. Fixed project deletion issues occurring on WEBHOOK type projects with SFDX/Sonar-Scanner
Several customers have reported unexpected issue under the specific circumstance of:
1. Create a WEBHOOK type empty project.
2. Run the analysis for the created empty type project using SFDX/Sonar-Scanner
3. The Analysis will be successful (as expected).
4. Then create a branch analysis for the same project type.
5. Switch the branch analysis to main branch analysis.
6. Then delete the project from Project settings.
Outcome:
Users are able to see that the project has been deleted successfully (expected behavior).
However, if users then search for projects, these users are able to see the project which was deleted previously. This is not expected behavior.
We have identified that the root cause of this issue is that the Project is not actually getting deleted when the default branch for a project is changed. This issue has been fully remediated with this fix.
Verified the fix via the following scenarios
Ran sonar-scanner analysis twice (one with branch) >> switch to other branch >> try deleting project >> user able to view successful message for deletion >> project deleted.
Verified with empty webhook project analysis as well.
Verified the below scenarios via the CodeScan APIs:
Verified Single project deletion and bulk project deletion
Verified Postman response - by giving security token and without security token
Verified deleting projects without having access
Verified deleting old projects.
2. Fixed issue where the bulk deletion of analyzed projects fails, while single project deletion works successfully
We have detected this issue under the following circumstance:
From the Project Management page, deleting a single project after a completed analysis works correctly. However, when multiple analyzed projects are selected and deleted in bulk, the deletion operation fails and throws error as "error": "org.hibernate.TransientPropertyValueException: object references an unsaved transient instance."
This issue has been remediated fully, so that all selected projects (analyzed) are deleted successfully (and the system shows proper confirmation messages (if required).
Verified the Bulk delete option for all project integrations, including comparison branches and regular branches. Confirmed via the following scenarios that users are now able to successfully delete multiple projects at once.
3. Fixed an issue in the rule “Immutable Field,” which was causing false positives {Rule ID: sf:ImmutableField}
Several customers have reported that the current rule logic incorrectly flags propertyVal as a candidate for final, even though its value can be modified indirectly through a property getter/setter. In the following example, the field propertyVal is updated within the getter of anotherPropertyVal via this.propertyVal = 'test' and subsequently returned:
Example code:
Expected Behavior: The rule should not raise a violation when the private field’s value can be modified through class property accessors (get/set methods) or other internal logic. Such fields are not immutable and marking them as final would cause compilation errors.
Verified that the “sf:ImmutableField” is getting triggered only when the private field’s value cannot be modified. Further, we verified the rule behavior using both mutable and immutable field patterns.
4. Fixed an issue in the rule “Type Reflection Is Security Sensitive” {Rule ID: sf:HotspotTypeReflection}
During our routine, internal rule evaluation process, we discovered that this rule wasn’t firing as expected. As such, we overhauled the rule logic to address this issue.
Verified the sf:HotspotTypeReflection rule by activating the rule in a specified Quality Profile. Then, in a subsequent project analysis, validated that the rule is now working as expected.
CodeScan Release 25.1.13
Release Date: 02 November 2025
Summary
CodeScan 25.1.13 is comprised of the following 5 components:
4 Rule Enhancements
1 Fix
Component details are listed in their corresponding sections within this document.
Rule Enhancements
1. Enhanced rule “Field Level Security” {Rule ID: sf:FieldLevelSecurity}
Previously, CodeScan did not raise violations if a method matched the condition:
This exception was originally introduced to reduce noise and was added to our rule logic before Salesforce introduced USER_MODE. However, with Salesforce’s updated guidance requiring all database operations to consistently enforce permissions, the exemption is no longer valid. Getters can still expose data through bindings, so excluding them would not align with best practices.
Now, DML operations in getter methods that do not enforce permissions (e.g., without USER_MODE) will correctly raise violations.
We have verified the rule logic and validated that users are able to see the violations for the getter methods on SOQL, DML operations.
2. Enhanced rule “Aura Controller Naming Convention” {Rule ID: sf:AuraControllerNaming}
Previously, CodeScan Controller Suffix in the rule Aura Controller Naming Convention was incorrectly case-sensitive. This meant that a violation was not triggered (expected behavior) when the suffix to controller (lowercase). However, if the class name instead included "Controller" (uppercase), a violation was being thrown (i.e., when we set ControllerSuffix = Controller).
Verified the below scenarios and validated that both are working as expected:
ControllerSuffix = "Controller"
ControllerSuffix = "controller"
Further verified the sf:AuraControllerNaming rule by setting ControllerSuffix = “Controller” in first run of Project and then changed ControllerSuffix to “controller.” Both projects triggered the same number of violations based on the provided data.
3. Updated the rule description for “God Class Rule” {Rule ID: sf:GodClass}
Description:
The God Class rule detects the God Class design flaw using metrics. God classes do too many things and are very big and overly complex. They should be split apart to be more object-oriented. The rule uses the detection strategy described in "Object-Oriented Metrics in Practice".
The God Class rule evaluates classes using the following three key metrics to determine size, dependency, and cohesion:
WMC (Weighted Methods Count): Measures the number and complexity of methods in a class. A high WMC indicates that a class has too many methods or overly complex behavior.
ATFD (Access to Foreign Data): Counts how many times a class accesses data from other classes. A high ATFD means the class is overly dependent on external data, reducing modularity.
TCC (Tight Class Cohesion): Represents how closely the methods of a class are related to each other. A low TCC suggests poor internal cohesion, meaning the class handles unrelated responsibilities.
Every violation will include three metrics: (configurable):
WMC: default > 47
ATFD: default > 5
TCC: default < 1/3 (33%)
The violations are reported against the entire class.
Verified the Update God Class Rule Description and confirmed that users are able to see the updated description for the rule.
4. Updated the rule descriptions for “CodeScan Other Rules” {Rule ID: cs-vf:unknown and Rule ID: cs-js:unknown}
We have updated the rule description for the rule "CodeScan Other Rules" rule key.
Updated Description:
This rule detects ESLint rule references written in code comments that are not currently recognized by the plugin. It helps identify placeholder or upcoming rules that may be added in future updates.
We have verified the Rule Description Updates on “CodeScan Other Rules (cs-vf:unknown and cs-js:unknown) and confirmed that users are able to see the updated descriptions.
Fixes
1. Fixed issue where issue page was not properly loading (under specific condition)
Several customers have reported that under the specific circumstance of:
Pull request > select any branch/pr > code > open any file and click on any issue message
Users are presented with a blank page instead of being redirected to the issue page.
This issue has been fully remediated with this fix.
Verified that users are now able to navigate to the Rule description page. Also verified that the “Why is this an issue link” (as well as other associated pages) are all working as expected.
CodeScan Release 25.1.12
Release Date: 19 October 2025
Summary
CodeScan 25.1.12 is comprised of the following 3 components:
1 New Feature
2 Fixes
Component details are listed in their corresponding sections within this document.
New Features
1. Better Management of CodeScan Orgs via Soft Deletion
Description
With this release, when an Admin performs an organization deletion, the org is maintained for an additional 30 days to allow for restoration (if needed).
However, please note that the org will immediately become inaccessible to all members, owners, and IDE users, and any tokens associated with it become expired. The deleted organization will remain in a disabled state for 30 days and can only be restored by an Instance-level Admin during this period.
We recognize that we can improve organization lifecycle management and data governance for our customers, while also reducing accidental data loss, by allowing Admins to restore orgs within 30 days.
Once an organization is deleted:
It will become immediately inaccessible to all non-admin users (members, owners, IDE users).
All API tokens and access credentials associated with the organization will be expired.
The deleted organization will be listed under a new "Deleted Orgs" section visible only to Instance-level Admins.
The deleted org is in a disabled state and cannot be accessed, modified, or used in any IDE integrations.
Instance-level Admins can restore the organization within 30 days of deletion.
After 30 days, the organization is permanently deleted unless restored.
Customers can notify us in writing to forgo the 30 days and have the instance deleted immediately, which we will perform at their request
Value / Purpose
Ensures security and compliance by revoking access and expiring tokens immediately upon deletion.
Provides control and flexibility to Instance-level Admins with a grace period for restoration.
Prevents data loss from accidental deletions.
Improves auditability and accountability in organization management.
Aligns with standard enterprise-grade administrative controls.
Fixes
1. Fixed issue where the IDE usage was not being captured properly
Several customers have reported that Admins are not able to see any details in the IDE Usage screen in their Org, while others reported that while they see the records, they do not see the records in Order.
We have determined the root cause to be a JDBC exception and have fully remediated both of these issues with this fix.
We have verified the fix via the following scenarios and confirm that Admins are able to see the correct records without any errors.
Admins can view all relevant details on the IDE Usage page after selecting the Individual tab.
Admins can also view the records displayed in the correct order under the All tab.
When the user selects "All" and filters the data for 120 days in the IDE Usage screen, the "Show More" option appears, allowing them to scroll down and view additional records from the last 120 days.
2. Fix to AvoidAbsoluteURL Rule
We have witnessed that, periodically, this rule does not seem to pick up new Salesforce URLs. As such, we updated the rule logic to detect and violate URLs matching the following patterns: {{*.salesforce.com}} {{*.force.com}} {{*.site.com}} {{*.documentforce.com}} {{*.marketingcloudapis.com}}.
We have verified the fix of the AvoidAbsoluteURL rule via the following:
Updated the rule to detect and flag violations for URLs matching the following patterns:
*.salesforce.com
*.force.com
*.site.com
*.documentforce.com
*.marketingcloudapis.com
We also verified that usage of any of the below URLs in the code now triggers a violation after activating the AvoidAbsoluteURL rule.
CodeScan Release 25.1.11
Release Date: 5 October 2025
Summary
CodeScan 25.1.11 is comprised of the following 5 components:
2 Application Enhancements
2 Rule Enhancements
1 Fix
Component details are listed in their corresponding sections within this document.
Application Enhancements
Update Project Analysis Subtitle Dynamically
Several customers have reported that, regardless of project analysis, each time a user attaches ANY analysis project to CodeScan, there’s a message that says, “Connects to your Salesforce instance.”
We recognize that when using *Project > Project Analysis*, the subtitle should dynamically update to display the text:
When the user selects *Salesforce* as ALM, the label updates to show: _“Connects to your Salesforce instance to execute a CodeScan analysis.”
When the user selects *Repository (GitHub, Bitbucket, GitLab)* as ALM for Project Analysis, the label updates to show: “Connects to your [ALM name] Repository to execute a CodeScan analysis.”
Further, the label must update in real time upon ALM selection, without requiring a page refresh.
This ensures the user clearly understands the connection purpose based on the selected ALM.
Verified the Update Project Analysis Subtitle Dynamically via the following scenarios:
Verified for the existing projects and newly created projects (all project integrations). The user is able to see the updated static description on the project analysis page as expected:
“Connects to your Salesforce instance or repository to execute a CodeScan analysis.”
New Version of CodeScan VS Code Extension (v 2.1.2)
Description
In the previous version of VS Code (2.1.1 and earlier), we had a reported bug: Issues that have been resolved in the UI are still showing in VS Code. In the past, these issues have been ignored and would be updated with a refresh of the connection.
In this updated extension, we have implemented improved synchronization of resolved issues from the CodeScan server, which addresses the reported issue.
Verified the VS Code plugin for the following file types: .cls, .page, .java, .js, .trigger, .css, .ts, .cmp.
Violations are appearing as expected in both the CodeScan environment and the VS Code plugin.
The resolution actions—Accept, False Positive, Confirm, and Fixed—are functioning correctly.
Verified the same functionality in the US PROD environment, which is working as expected and consistent with the TEST environments.
Verified the VS Code plugin on the self-hosted environment. After the user refreshes the connection, the resolutions are displaying as expected.
Also verified on the Self-Hosted environments (SQ versions 25.1 and 25.2):
When the user sets an issue as False Positive or chooses to Accept the issue, the issue count is reduced on the UI as expected.
Rule Enhancements
Enhancement to “sf:AvoidLogicInTrigger” Rule
Historically, this rule finds any blocks of code in a trigger and throws a violation.
In this enhancement, we added a parameter to the rule allowing users to add a comma separated list of trigger frameworks that are allowed.
The new parameter is “allowedTriggerFrameworks.”
Description: A comma separated list of Trigger frameworks to allow. Violations will still be reported if complex logic is present within the allowed parameters.
For more information, please review an overview of triggerframeworks: https://www.saasguru.co/salesforce-trigger-frameworks-guide/?srsltid=AfmBOopNA_BxSsI_tjZ1EGP3n59fi-_TW5Q-TQaoFFv1tIIYKZEyDJ5f
Details of the new parameter:
Allow:
Trigger.is* checks
Direct calls to whitelisted methods/properties (including inside conditions or assignments).
Flag:
Any iteration (for, while, do) in a trigger is a violation, regardless of whitelist.
Any non-whitelisted method calls.
Any direct DML, SOQL, or field logic.
Variables assigned from whitelisted methods used later in invalid contexts (like while(var)).
Verified the new parameter on the sf:AvoidLogicInTrigger rule to ensure compatibility with trigger frameworks via the following scenarios:
Any control statement with {} (e.g., if, for, switch) in trigger body → Violation.
Exception: if that uses Trigger.is… → No Violation. However, if Trigger.is… appears inside a for loop, it’s still a Violation.
If a method is added to the rule parameter (allow-list) (e.g., checkPermission), then an if using it → No Violation.
But: for, while, do-while, SOQL, DML → always Violation (allow-list does not suppress these).
Enhancement to “Use Annotation on Test Class” Rule
During our routine testing of our rules, we noted that this rule is outdated, as it only detects the testMethod keyword. It does not work with the newer @IsTest annotation, causing missed violations in modern Apex test classes.
Fix Updated the rule logic to support detection of @IsTest annotation on test classes, ensuring compliance with current Apex best practices.
Verified the enhanced rule logic in “Use Annotation on Test Class” in the following scenarios:
A non-test class or Utility class without test methods → Verified: No violation raised.
@IsTest annotated class with test methods (@IsTest and/or testMethod) → Verified: No violation raised.
Class containing only testMethod methods without @IsTest → Verified: Violation raised.
Class containing only @IsTest methods without class-level @IsTest → Verified: Violation raised.
Fixes
Fixed Application Issue where the “Issues Filter” was not working as expected with CWE tags.
Several customers have reported that the Issues Filter does not work with CWE tags. Although individual issues correctly display their associated CWE ID, searching or filtering by a specific CWE ID in the Issues view will sometimes return no results.
We have identified that the root cause of the issue was that the CWE filter for Issues and Rules was limited to display and filter through only 10 items in the filter dropdown. Therefore, we expanded the filter limit to display up to 100 items and enabled input-based search across all options for enhanced usability and consistency.
After extensive research, we concluded:
Rules page – CWE search
In the Rules page, only the first ~10 CWE entries show up under the search. Beyond those, no additional rules appear when searching by CWE.
Issues page – CWE filter
Issues do show up for certain CWEs, but not consistently. Example: an issue mapped to CWE-470 appears, yet the same issue also mapped to CWE-80 does not appear when searching for 80.
When a rule/issue has multiple CWE values, the CWE filter on the Issues page sometimes returns results for only one of those CWE values, not all.
Filter/search behavior
The CWE filter search bar does not call an API while you type. It only searches within the already-fetched list from the backend.
An API request is made only after you click/select a specific CWE from that list to load rules/issues for that CWE.
Technical details (implementation)
standardfacet.tsx renders the CWE filter component; handleSearch manages the in-filter search behavior.
Standards.json lists CWE values and descriptions. Even after adding additional CWE entries into this file, those new values still don’t appear in the filter list.
Conclusion: The filter list is not driven solely by Standards.json, or it’s being constrained elsewhere.
Data/API status
Database: Contains all rules with their full set of CWE values.
API: Works as expected when calling with cwe=<value>; results return correctly. The inconsistency happens only in the filter UI, so we should inspect the UI-side response and check for any server or client-imposed limits on the number of CWE results returned.
We have remediated these issues with this fix.
Verified the fix for “Issues Filter is not working with CWE tags” via the following scenarios.
Searching or filtering by a specific CWE ID in the Issues page under Security Category is working as expected.
Verified that the Show More button under the CWE filter works correctly, with the default filter count set to 15.
Even when the CWE filter is limited to the default 15 entries, searching for an ID like CWE-16 still returns the correct result for the user.
CodeScan Release 25.1.10
Release Date: 21 September 2025
Summary
CodeScan 25.1.10 is comprised of the following 9 components:
1 New Feature
8 Rule Enhancements
Component details are listed in their corresponding sections within this document.
New Features
CodeScan now imposes verification logic on email signup to enhance security. Previously, users were able to register and log in without verifying their email. We recognize that this could potentially lead to the creation of fake or fraudulent accounts. In this release, we have implemented an email verification via unique links to a one-time verification link. Additionally, we have added logic that restricts access to functionalities for unverified accounts. Verified the Migrate email verification Rule to Action in Auth0 via the following scenarios: After signing up, the user receives a verification email. Only after successfully verifying the account, the user is able to log in to the instance as expected.
Rule Enhancements
Enhancement to sf:ServerSideRequestForgery Rule As part of the CodeScan 25.1.2 release (June 2025), we added this new rule (Server Side Request Forgery). We have had several customers request an enhancement to this rule, as they reported that this rule was not catching all of the SSRF issues. As such, we have enhanced this rule to find all the sinks for these issues with concatenated URLs to all methods that take an HttpRequest as an input. This is the list of methods we have added as sinks (these are in addition to the issues that this rule is currently finding):
Http.send(HttpRequest)
HttpRequest.setEndpoint(String)
Continuation.addHttpRequest(HttpRequest)
PageReference.getContent() Verified that the rule ServerSideRequestForgery is throwing violations when the following methods are used in the code:
HttpRequest.setEndpoint(String)
PageReference.getContent()
Enhancement to Resource Injection Rule As part of the CodeScan 25.1.2 release (June 2025), we added this new rule (Resource Injection). We have had several customers request an enhancement to this rule, as they reported that this rule was not catching all of the issues. As such, we have enhanced this rule to find all the sinks for these issues with concatenated URLs to all methods that take an HttpRequest as an input. This is the list of methods we have added as sinks (these are in addition to the issues that this rule is currently finding):
Http.send(HttpRequest)
HttpRequest.setEndpoint(String)
Continuation.addHttpRequest(HttpRequest)
PageReference.getContent() Verified that the rule Resource Injection is throwing violations when the following methods are used in the code:
HttpRequest.setEndpoint(String)
PageReference.getContent()
Enhancement to “Switch Statements Should Have a When Else Case” Rule Currently, the rule is not working as expected, as it does not raise violations when a switch statement lacks a when-else block. We have modified that logic to correctly identify switch statements that are missing a when-else case so that users can ensure the code is more robust, future-proof, and does not miss handling unexpected cases. Example:
Verified that the updated rule now correctly flags switch statements without a when-else block, ensuring violations are raised consistently for missing default cases.
Enhancement to “Avoid Reversed Operators” Rule Modified the rule logic to correctly detect and report improper usage of reversed operators (=-, =+) in Apex code, so that users can avoid mistakes where variables are unexpectedly reassigned rather than incremented/decremented. Current Behavior:
Violations are not raised when using reversed operators like target =- num; or target =+ num;. Expected Behavior:
The rule should detect and flag cases of reversed operators (=-, =+) and provide a clear violation message.
The violation message should explain the confusion:
x =- y; assigns -y instead of subtracting.
x =+ y; assigns +y instead of adding.
This new logic will prevent developers from introducing subtle logic bugs caused by operator misuse. Further, we updated the rule example with the following:
Verified the new logic via the following scenarios: 1. Rule sf:AvoidReversedOperators raises violations for reversed operator cases (=-, =+).
2. Rule does not raise false positives on valid operator usage (+=, -=).
Enhancement to “CouplingBetweenObjects” Rule Modified the rule logic to correctly detect and report violations so that users can identify classes with excessive dependencies and reduce code complexity for better maintainability and testability. Verified that the violation is triggered when the number of classes used exceeds the defined threshold value in the rule parameter (for example, if the threshold is set to 4 and 5 classes are used, a violation will be raised).
Enhancement to “Avoid Insecure Digest Algorithms” Rule Enhanced the current rule logic to correctly raise violations when MD5 or SHA-1 algorithms are used. Since these algorithms are cryptographically broken and vulnerable to hash collision attacks, their continued use poses a security risk. The rule should:
Detect any instance or usage of MD5 or SHA-1 for hashing/digesting.
Report violations with clear remediation guidance.
Suggest secure alternatives such as SHA-256 or SHA-512. Verified the new logic via the following scenario: Validated that users are able to see a violation for the rule AvoidInsecureMessageDigests. This violation indicates the use of insecure message digest algorithms such as MD5 or SHA-1.
Enhancement to “Add Empty String” Rule Updated the rule logic to identify and flag expressions where literals are concatenated with an empty string (e.g., "" + 123 or 123 + ""). Also ensured that violations are reported with a clear message and that valid concatenations and type-specific toString() methods are not falsely flagged. Verified the below scenarios all are working as expected. 1. Empty string with numeric or Boolean literals Examples: '' + 123, 123 + '', '' + -42, '' + 3.14, false + '', '' + true 2. Empty string with string/char literals or inside chains Examples: '' + 'abc', 'abc' + '', 'A' + '' + 'B', 1 + '' + 2 3. Empty string literals inside parentheses Examples: ('' + 1) + 2, 1 + ('' + 2) 4. Empty string at start of long chain with literals and variables Example: '' + 123 + 987 + var1 + var2 5. Empty string used with - operator and literals Examples: '' - 123, 123 - '', '' - -42
Enhancement to “Avoid Hard-Coded Resource References” Rule Enhanced the rule logic to identify hard-coded file path references and raise violations with a clear issue message. Validated the logic by verifying that users are able to see the violations for the use of the attribute value that starts with '/resource/'.
CodeScan Release 25.1.9
Release Date: 07 September 2025
Summary
CodeScan 25.1.9 is comprised of the following 4 components:
2 Enhancements
2 Fixes
Component details are listed in their corresponding sections within this document.
Enhancements
Enhancement to Suppress Warnings Rule
Our rule TrackSuppressWarnings had logic to find @SuppressWarnings, but the logic didn’t include find @suppresswarnings.
This suppression tag works in any case and we recognized that our TrackSuppressWarnings rule needs to do the same (meaning the rule needs to be case insensitive.)
This logic was added to this rule in this enhancement.
Verified the SuppressWarnings Rule enhancement and validated that the suppression tag is working in all case-insensitive instances and our TrackSuppressWarnings rule is throwing violation for all cases.
Rule Enhancement for sf:UnusedFormalParameter
In this rule enhancement, we introduce a configuration flag (ignoreUnusedParametersInInterfaceOverrides) in the sf:UnusedFormalParameter rule so that unused parameters in valid interface implementations and method overrides can be conditionally suppressed. By default, violations will continue to be reported unless this flag is explicitly set to true.
How to Identify These Parameters for Suppression
When designing your rule improvement, the logic should:
1. Check if the method is implementing a known Salesforce interface method:
Use method signature matching (name, parameters, visibility).
Confirm the containing class uses implements keyword for one of the known Salesforce interfaces.
Ensure parameter types match exactly, e.g., SchedulableContext, Database.BatchableContext.
Visibility Enforcement
Only suppress violations if the method visibility is public or global, as required by the platform.
Private or protected methods should never be eligible for suppression under this rule.
This ensures that suppression only applies to methods actually callable by the platform or conforming to Apex interface rules.
3. Override Detection
If a method in a class overrides a method from a superclass or an abstract class:
Signature match is mandatory (same name, return type, and parameters).
Use of the override keyword confirms the intent, but even without it, structural matching should be enough.
In such cases, the parameter should not be flagged if unused, since it’s required by the parent contract.
Value / Purpose
Prevent misleading or incorrect violations in valid interface and override implementations (e.g., execute [SchedulableContext]).
Preserve backward compatibility by keeping the rule strict by default.
Additionally, we updated the Rule Description to “Avoid passing parameters to methods or constructors without actually referencing them in the method body. Use the ignoreUnusedParametersInInterfaceOverrides parameter to suppress violations for unused parameters in valid interface implementations and method overrides.”
Verified the rule sf:UnusedFormalParameter and validated the following conditions:
The method implements a known Salesforce interface method.
Method signature matches exactly in terms of:
Name
Parameters
Visibility
The containing class uses the implements keyword with one of the known Salesforce interfaces (e.g., Schedulable, Database.Batchable).
Parameter types match exactly, including types such as:
SchedulableContext
Database.BatchableContext
Fixes
Fixed issue with CodeScan rule detecting SOQL Injections, which was causing analyses to break.
Previously, while analyzing for SOQL Injection, if a local variable is declared using a class-level variable of same name, then CodeScan analyses were erroring with StackOverflowError as it was stuck in a loop while resolving the reference.
Example:
class Foo { private static String QUERY = 'Select '; public static List<Opportunity> getData(String stage) { String query = QUERY + 'Id FROM Opportunity WHERE StageName = :stage'; return Database.query(query); } }
With this fix, we added validation to detect and prevent such recursive reference resolution.
Verified the SOQL injection rule fix (which was causing stack overflow error) by validating that now users are not encountering the error, and their project analyses are working as expected.
Fixed an Error that was occurring when Deleting CodeScan Projects
Some customers have reported that when attempting to do a project deletion, the task sometimes fails. We have determined that the root cause is that the system is trying to fetch project details after the project has already been removed, which leads to missing information and, subsequently, unexpected errors.
This fix includes logic to delete projects properly.
We have verified the fix for Error When Deleting CodeScan Projects and validated that users are able to delete their projects without any errors.
CodeScan Release 25.1.8
Release Date: 31 August 2025
Summary:
CodeScan 25.1.8 is comprised of the following 1 component:
1 Fix
Component details are listed in their corresponding sections within this document.
Fixes
Fixed issue where CodeScan Project Analysis jobs getting stuck at "finalizing" stage.
Previously, CodeScan project analysis jobs were getting stuck at "finalizing" stage, and not returning the result to GitHub PR, thus blocking all PRs.
The root cause of the issue was that db-pool-limit-reached was occurring. This fix remediates this issue.
After applying the fix, we validated the fix by creating jobs with alternating pass/fail quality gate statuses. Once the fix had been applied, we observed all jobs completing successfully (without getting stuck) We also verified the below Audit log cases:
Verified the category "PROJECT_ANALYSIS" and checked the below details that are stored in the logs all are appearing as expected.
Project Names
Project Keys
Lines of code count - split by ncloc languages
Created date
First analysis date
Also, Verified the category Quality Gates and checked the below details which are stored in the logs all are appearing as expected.
operation": "UPDATE",
propertyValue": "Failed/Passed”
createdAt": “*****”
componentKey
componentName componentUuid
CodeScan Release 25.1.7
Release Date: 24 August 2025
Summary
CodeScan 25.1.7 is comprised of the following 5 components:
1 New Feature
4 Fixes
Component details are listed in their corresponding sections within this document.
New Features
Enable/Disable feature of Mapping to multiple orgs from one SAML Connection at instance level.
This new feature enables customers to map to multiple orgs from one SAML Connection at their instance level.
Verified the following scenarios for SAML users, and all scenarios are working as expected.
Verified the User when CodeScan idp-group-mapping is disabled, user is able to log in through SSO when the Group synchronization and IDP mapping is not used.
Verified the User when CodeScan idp-group-mapping is disabled, user is able to log in through SSO when the Group synchronization and IDP mapping are used.
Verified the User when CodeScan idp-group-mapping is enabled, user is able to log in through SSO when the Group synchronization and IDP mapping are used.
Verified the User when CodeScan idp-group-mapping is enabled, user is able to log in through SSO when the Group synchronization and IDP mapping are not used.
Validated the SAML connection creation and login through SSO in the created Org.
Validated the SAML connection creation and login through SSO with the other Org.
Created a new user and checked the login through SSO with the same above SAML config.
Verified the IDP group mapping where the user is mapped to the organization where SAML connection is created.
Fixes
Fixed Broken Documentation Link in Status Module
It has been reported that the "Status" module in all CodeScan application contains a broken documentation link: https://knowledgebase.autorabit.com/user-guide/issues/solution-overview/#life-cycle
This link provides users with detailed information on the lifecycle of issue statuses but currently leads to a nonexistent page. The correct, working link should be: https://knowledgebase.autorabit.com/product-guides/codescan/issues/about-issue-status
This fix remediates this issue in full.
Verified the fix by confirming that the documentation link under the "Status" tab in the Issues module has been updated and now redirects to the correct Knowledge Base page. The link is updated to About Issue Status | AutoRABIT Knowledge Base
URIs are not Valid in decorated SARIF output
It has been reported that the URLs are not valid in the SARIF file due to spaces. To remediate, we added logic to make certain that they are escaped.
Verified that users are now able to see valid URLs in the SARIF report even when the file names include underscores, numbers, hyphens, special characters, with spaces.
Fixed issue where scheduled analyses are not running for SF projects and its comparison branches
Several customers have reported that their daily scheduled analyses were not running for Salesforce integration projects and their corresponding comparison branches within the same project. We determined that the Scheduled Jobs were getting stuck, even though they were consuming memory and CPU. Further, we identified that the root cause of the issue stemmed from changes made in the previous release (25.1.6), and that scheduled jobs on our AWS infrastructure were running into “out-of-memory” issues.
This fix remediates this issue in full.
Verified the fix and validated that the scheduled jobs are now running without issue (as expected).
Fixed issue with deleting branches in projects using Salesforce Integration
We uncovered that if the following steps were performed…
1. Launch and log in to the CodeScan application and be on any org. 2. Create Salesforce project. 3. Create comparison and standard branch analysis. 4. Try deleting comparison branch.
…then users receive an error message indicating that an “unknown error occurred.”
This issue has been fully remediated in this release.
We have verified the fix and have validated that the following scenarios are all working as expected: 1. Verified salesforce comparison branch deletion. 2. Verified creation of project with user having (create and analyze project permissions). 3. Renaming of project branch. 4. ALM project tags working as expected.
CodeScan Release 25.1.6
Release Date: 3 August 2025
Summary
CodeScan 25.1.6 is comprised of the following 6 components:
1 New Feature
3 Enhancements
2 Fixes
Component details are listed in their corresponding sections within this document.
New Features
Categories for Project Types
Often, customers will have a lot of projects in CodeScan. Several customers have requested the ability to filter their projects by the type of integration including:
GitHub: github Bitbucket: bitbucket GitLab: gitlab Git: git Salesforce: salesforce
To deliver this feature, we created custom tags with the ability to add these tags when new projects are created.
Unlike most tags, we designed integration type tags to remain once assigned. If the user tries to remove it the following error will occur: “Integration type tags cannot be removed from projects.”
NOTE: Due to the change in permissions needed in the API for these tags to be added, we also adjusted the text in the API doc as well. For the endpoint api/project_tags/set the text now states:
“Requires the ‘Administer’ or ‘Create Project’ permissions on the specified project.”
Here are the tag API references: CodeScanCloud
Verified Categories for Project Types in the following scenarios, and have verified that all are working as expected:
Verify that the user is able to see the correct tag for the project on the Project Information page after completing the analysis. Example: For a Salesforce integration, the tag should display as “Salesforce.”
Verify that the user is able to see the correct tag for each project integration under the "Tags" column in the Projects tab of the organization. Example: For a Salesforce integration, the tag should display as “Salesforce.”
Verify that the user is able to see the correct tag for each project integration under the "Tags" column in the My Projects tab. Example: For a Salesforce integration, the tag should display as “Salesforce.”
Verify that the user is not able to remove an existing tag or add a tag of a different integration tag to the project.
Verified that clicking on a tag correctly displays the associated projects, with accurate project count and correct project listings.
Enhancements
1. Users getting error when trying to restore quality profiles.
Currently, when a Quality Profile import fails, CodeScan displays the following error: "An error occurred. Please contact your admin."
We recognize that it would be a better experience (and more helpful) to make this error more verbose to allow the customer to remediate the issue themselves. Mostly these errors are thrown because of a rule present in their Quality Profile which is not present in their organization. In these cases, the error message is now “An error occurred. A rule in your Quality Profile is not available in this organization.”
The second most common error occurs when the QP is corrupted or malformed. In these cases, the error message now states “An error occurred. The Quality Profile backup is malformed. Please export your Quality Profile again.”
We believe that these more verbose error messages will help our customers remediate their issue much more easily. However, if they require assistance, they can create a support ticket.
Verified this enhancement via validating the below scenarios
If a malformed QP (with no profile name/language) is imported, an error message is shown.
When importing a QP with custom rules from another instance, those custom rules are also created during import.
If the imported QP has no profile language, the error message says: "Profile language should be set."
If the QP has no profile name, the error message says: "Profile name should be set."
If no file is selected during import, an error occurs.
If the repository key is missing, an import error is triggered.
If a QP with profile name CodeScan way/CodeScan strict way/CodeScan nCino way name is imported, an error is thrown.
2. Pagination in Projects and Previous Analysis
To provide a better experience, we have added separate pagination controls, allowing users to navigate Projects Analysis and Previous Analysis sections more easily. This enhancement includes Projects Analysis displaying 10 entries per page and Previous Analysis displaying 15 entries per page. This allows the user interface to remain responsive and readable even when there are many entries.
Verified the Pagination enhancement via validating the following scenarios:
The Projects Analysis section displays a maximum of 10 entries per page.
The Previous Analysis section displays a maximum of 15 entries per page.
Pagination controls (e.g., next, previous, specific result numbers) are present and functional in both sections independently.
3. Email Limit & Validation for Multi-User Invites
To improve the user experience for admins inviting users to their CodeScan org, we have implemented the ability to invite multiple users at once (up to 50) using the same user type (Standard User or Platform Integration User). Additionally, this enhancement ensures that only valid email addresses are accepted in the batch. This ensures that the invite experience remains consistent and controlled; additionally, user onboarding will be faster and more efficient. Further, Admins are still able to maintain control over user type classification, email validation, and system performance.
The main components of this enhancement are:
Added each email on a new line.
Text was added in UI beside Email option for multiple users invite option.
Add the following error during limit exceeded scenario: “Invite limit exceeded. Max 50 emails allowed.”
Value / Purpose:
Streamlines onboarding by allowing multiple users to be invited in one action.
Maintains role clarity by restricting each batch to a single user type (Standard or Platform Integration).
Improves system integrity and reliability by validating email format and capping batch size.
Prevents errors and abuse by limiting the invite size to a maximum of 50 and checking for valid emails only.
We have verified the enhancement for Email Limit & Validation for Multi-User Invites by validating the following scenarios:
Verified that if invite is sent to more than 50 members, then the following is thrown:
Invite sent successfully if invite is sent to less than or equal to 50 users.
Verified, if mail address is more than 100 characters, then an error is thrown; if it is less than 100 characters, then the invite is sent successfully.
If invite sent to non-corporate domains, the following error is thrown:
Fixes
1. Align CSV Export filter status with Latest SQ Issue status
This enhancement implements issue status values in the CSV export filters to reflect the latest status terminology introduced after CodeScan 25.1.0 release (which occurred in April 2025). Prior to this enhancement, the filters in CSV Issue Export were showing outdated statuses such as Opened, Confirmed, ReOpened, Resolved, and Closed. This was in contrast to the updated statuses including Open, Accepted, False Positive, Confirmed, and Fixed. This inconsistency was reported by several users who cited confusion and data integrity issues when analyzing or reporting exported results.
Value / Purpose:
Ensures consistency between issues UI and CSV exported data.
Improves user trust and understanding of exported scan results.
Acceptance Criteria
Status Values in Export:
Legacy Status Replacement:
Filter Cleanup:
UI-CSV Consistency:
Backward Compatibility:
Existing historical issues should reflect the new status names in the export, even if their status was stored using legacy labels.
Verified this enhancement by validating the following scenarios:
Status Values in Export:
The issue statuses in the exported CSV must match the latest values of Open, Accepted, Confirmed, False Positive, and Fixed Legacy Status Replacement:
Legacy status values such as Opened, Confirmed, ReOpened, Resolved, and Closed must no longer appear in the exported CSV.
These must be correctly mapped to the corresponding updated status where applicable.
Filter Cleanup:
The Resolutions filter should be completely removed from the CSV Export page.
The Is Resolved filter should be completely removed from the CSV Export page.
Only the Status filter should be visible and functional.
UI-CSV Consistency: The status shown in the exported CSV for each issue must exactly match what is shown for the same issue in the UI.
The type, statuses and severity shown in the exported CSV is exactly matching what is shown in the issues page and CSV export page.
Fixed an unclear error message displayed when invite is sent only to non-corporate email addresses
This fix addresses an unclear message that occurs when:
Admin clicks on "Invite user"
Admin enters only non-corporate email addresses (e.g., Gmail, Yahoo)
Admin clicks "Send Invitation"
After these steps, Admin receives the following unclear error message:
However, this issue does not occur when multiple users are invited, including at least one corporate email:
This issue has been fully remediated. We have verified the fix via the following scenario: Validated that the proper error message is displayed when invite is sent only to non-corporate email addresses.
CodeScan Release 25.1.5
Release Date: July 20, 2025
Summary
CodeScan 25.1.5 is comprised of the following 17 components:
· 4 New Features
· 2 Enhancements
· 4 Fixes
· 1 Revenue Org Improvement
· 6 Architecture Improvements
Component details are listed in their corresponding sections within this document.
New Features
Support Intelligent Prompts for A.I. LLMs
CodeScan can now generate prompts for LLMs including Agentforce, Copilot, ChatGPT, and Claude AI. This feature is a component of the CodeScan extension for VS Code.
Requirements:
Your CodeScan environment must be running version 25.1.5 (or higher). In addition, you need to be running the latest version of the CodeScan VS Code extension (v 2.1.1), which can be downloaded here: https://marketplace.visualstudio.com/items?itemName=codescansf.codescan-vscode
What Problem Are We Solving?
Adoption of AI can be challenging for companies for several reasons. CodeScan can help catalyze your AI initiatives.
User Benefits
• Generate prompt in the IDE
• Directly update existing code with generated code
• Ensures security issues are addressed
Verified Intelligent Prompts for cls, page, component, trigger, and cmp files, all working as expected by validating the below scenarios:
1. Able to click generate prompt and copy it
Able to paste the generated prompt in the Agentforce search box
Able to receive the message prompt copied to clipboard after generating prompt.
Able to receive a message stating that the file is too long; please select the impacted lines of code and click "Generate Prompt" if the selected file has more than 1,000 characters.
Able to copy the code generated by Agentforce as expected
CVSS Implementation for Security Vulnerabilities
The Common Vulnerability Scoring System is a technical standard for assessing the severity of vulnerabilities in computing systems. Scores are calculated based on a formula with several metrics that approximate ease and impact of an exploit. Scores range from 0 to 10, with 10 being the most severe. In this release, CodeScan has applied this quantitative scoring to all security vulnerabilities, allowing organizations to more systematically prioritize the security remediations.
The following metrics were used to generate our CVSS scores:
Base Score Metrics
Attack Vector (AV) (specify)
Attack Complexity (AC) (specify)
Privileges Required (PR) (specify)
User Interaction (UI) (specify)
Scope (S) (specify)
Confidentiality Impact (C) (specify)
Integrity Impact (I) (specify)
Availability Impact (A) (specify)
Temporal Score Metrics
Exploit Code Maturity (E) (specify)
Remediation Level (RL) (specify)
Report Confidence (RC) (specify)
Environmental Score Metrics
Modified Attack Vector (MAV) (specify)
Modified Attack Complexity (MAC) (specify)
Modified Privileges Required (MPR) (specify)
Modified User Interaction (MUI) (specify)
Modified Scope (MS) (specify)
Modified Confidentiality Impact (MC) (specify)
Modified Integrity Impact (MI) (specify)
Modified Availability Impact (MA) (specify)
Confidentiality Requirement (CR) (specify)
Integrity Requirement (IR) (specify)
Availability Requirement (AR) (specify)
Verified the CVSS range from 0 to 10, where users are able to see the CVSS violations for the below rules as expected.
OpenRedirect
CustomFieldSecurityInStandardObject
SOQL Injection
FieldLevelSecurity
Verified the CVSS Category on RULES page, ISSUES page and also verified the CVSS issues for the specific analysis.
3. When encountering an Incorrect Custom XPath rule, CodeScan Analysis continues
Currently, if a customer’s Xpath Rule has incorrect XPath syntax, an error is shown in the analysis log and no further checks are run on the file that the custom rule was being applied to.
We decided to make this more visible to users, as there was no further explanation of skipping the file outside of reviewing the associated logs. Instead, users would see the issues disappearing from their files.
In this release, the following improvements were added:
one incorrectly formatted custom rule shouldn’t stop the processing of all rules on a file
created a project level rule that triggers a violation when this issue occurs
implemented the logic for a project level violation that appears when this issue occurs
created an associated message: “The custom XPath rule {rule key} failed to parse. Your {language} files were not able to display this issue. Please check your custom rule in the rule designer before your next analysis”
Define User Type While Inviting or Adding Member
CodeScan now allows admins to define the user type when inviting or adding a member (either "Standard User" or "Platform Integration User"). This ensures that each user is onboarded with the appropriate role, purpose, and permissions.
Since the system now allows for the designation of users as either Standard Users or Platform Integration Users during the invitation or member addition process, admins are now able to manage users more effectively (and thereby Ensuring Standard Users have the appropriate access (All the features of CodeScan), and Platform Integration Users are recognized distinctly for integration IDE purposes (or similar integration purposes).
Value / Purpose:
Improves access control by ensuring correct user roles at the point of entry.
Differentiates Standard Users from Platform Integration Users for better tracking and reporting.
Enhances audit logs, billing accuracy, and license management.
Reduces post-invite administrative tasks by setting the correct user type up front.
Supports security and compliance needs by maintaining a clear separation between user types.
Verified the ability to define User Type While Inviting or Adding Member by validating the below scenarios:
Admin must be able to select the user type ("Standard User" or "Platform Integration User") when inviting or adding a member.
The user type selection must be a required field.
"Standard User" should be the default selection.
Selected user type must determine the role and permissions automatically:
Standard Users get full access to all CodeScan features.
Platform Integration Users get limited access scoped to integration IDE tasks.
User type must be clearly labeled in the member management.
“Platform user cannot be added to the Owner group.” — should be displayed when the Owners group is selected for a Platform user. Additionally, the Send Invite button should be disabled in this case.
For multi-user invites, the flow should be the same as for a single invite. Invites can be sent in batches, but only for one user type at a time.
Able to see the standard and platform user type while adding a member to the organization
Enhancements
Add ESLint rules from @lwc/eslint-plugin-lwc
CodeScan has traditionally provided ESLint rules within our rules library. Separately, Salesforce has an official ESLint plugin to analyze LWC code:https://github.com/salesforce/eslint-plugin-lwc.
The rules in this plugin are different to our current set and expand on it; expanding the rules in our LWC set is vital to support the needs of our customers using Lightning Web Components.
Our aim was to include all rules from the GitHub - salesforce/eslint-plugin-lwc:
Official ESLint rules for LWC repository added to our current list. However, there are a few rules from this plugin that were not included.
Rules that weren’t added as part of LWC set:
Disallow duplicate class members (no-dupe-class-members). This wasn’t added because it’s a Deprecated Rule
Additionally, we did not include these 3 rules because of the Complex Parameter Type:
Enforce wire adapters to be used with wire decorator (no-unexpected-wire-adapter-usages)
Disallow usage of unknown wire adapters (no-unknown-wire-adapters)
Disallow access to global browser APIs during SSR (no-restricted-browser-globals-during-ssr)
Note that all of these LWC rules were added to our Salesforce Lightning Quality Profile.
Verified the Add Eslint rules from @lwc/eslint-plugin-lwc for the below scenarios: 1. Verified the 21 rules from the GitHub - salesforce/eslint-plugin-lwc: Official ESLint rules for LWC repository added to our Salesforce Lightning Quality Profile of javascript language. 2. Verified the Description, Rule Details, Type of issue, Remediation function, Severity for all the rules. 3. Verified that new rules is not included in the default Quality Profile. 4. Verified that violation is thrown for all the 21 rules.
Enhancement to Apex rule “Unused Formal Parameter” {sf:UnusedFormalParameter}
CodeScan has offered this rule since Dec 2017. Recently a customer reported that Unused Formal parameter doesn’t find when variables used in SOQL. We replicated this issue where CodeScan flagged a variable as an unused variable even though it is used in the SOQL string.
We have enhanced this rule to detect additional cases where string parameters are part of SOQL. The rule now detects cases where string params are used as part of building soql query.
Verified the enhanced logic of rule “UnusedFormalParameter” via the following scenarios. 1. Previously, a parameter (e.g., encounterIds) used in a SOQL string (e.g., WHERE Id IN :encounterIds) was wrongly reported as unused. Now, this is correctly detected as usage — no violation.
Also verified below cases all are working as expected Verified: Parameter used in SOQL with bind variable (:encounterIds) — no violation Verified: Parameter used via clause string assembly — no violation Verified: Parameter incorrectly concatenated into SOQL string — violation Verified: Parameter declared but not used anywhere — violation
Fixes
Fixed issue ARM users recieving an error: “Component can't be null” while running a CodeScan analysis from ARM.
The issue is occurring in the SFDX retrieval. From ARM, when the user commits only the fields (or, for example, lookup fields), the .object-meta.xml is not retrieved. As a result, the retrieved file structure differs from what was expected. After analysing the rule’s implementation, it was found that the rule does not check if the .object-meta.xml file exists first and forcibly tries to throw the violation on the file. Hence, the "component can't be null" error is thrown. This required an engineering fix in the rule.
Note: The issue lies in one of the common methods many rules use, so this error is not confined to these two rules.
Other rules that use this method include:
With this fix, users are now able to see the violations for all 7 rules when running a CodeScan analysis from the ARM side using the CodeScan plugin:
Rules:
sfmeta:CrossObjectFormulaOveruse
sfmeta:ObjectLookupsOveruse
sfmeta:RelationShipOveruse
sfmeta:ExternalIdOveruse
sfmeta:RollUpOveruse
sfmeta:LimitCustomFields
sfmeta:nCinoFieldHistoryTracking
Verified by committing only specific fields and triggering SCA analysis — violations appeared as expected.
Ran analysis for the entire Salesforce org, including objects — violations were also detected."
Fixed issue where after a user is deactivated, the user is still displayed on Members page
Some users were reporting that after a user is deactivated, the user is still displayed on the Members page.
Detailed Solution
Made changes in the codebase to remove the user from members table when the user is deactivated.
Enusresd that using “search” on the Members page only active users are retrieved.
The user is no longer able to login via SAML
Verified the below scenarios regarding users being displayed in Members page, and all scenarios are working as expected.
Create and Activate New User- User appears under the Members list of the active organization
Add User to Inactive Organization- User is visible under the Members list of the inactive organization
Deactivate User from Instance- User no longer appears in the Members list. Behavior confirms that deactivated users are excluded from the UI display
Verify SAML Login for New User- Authentication via SAML was successful
Billing Page User Count Verification- User count reflects the new user addition appropriately. Billing data is updated as per user assignments
Fixed issue with rule “Avoid running Soql and DML inside loops” {sf:AvoidSoqlInLoops}
Recently, some customers reported unexpected behavior in this rule, producing false positives.
The root cause of the false positives is that when a method of an object is invoked within another method, and both methods share the same name, the current rule implementation incorrectly interprets this as a recursive call and subsequently triggers a violation. Further, the Stack Loop trace is indefinite.
This had been remediated in a previous release (25.1.2 release in June 2025). The updated rule logic now handles these edge cases by checking for method image to be exactly the same (method != diffObj.method).
However, there’s more to this issue and fix! A scenario which was earlier covered stopped working as expected as a result of the fix made above. This new issue was reported to us, and has been fully remediated in this release by adding additional logic to the rule implementation was made to accommodate both scenarios (the pre-existing condition but also indefinite stack loop trace).
Verified the Fix for rule sf:AvoidSoqlInLoops via several scenarios, including:
Verified – SOQL inside a method (not directly in a loop) — no violation as expected
Violations Expected for the below scenarios
Verified SOQL directly inside a for loop — got violation as expected
Verified SOQL inside nested if blocks within a loop — got violation as expected
Verified SOQL inside a try/catch block within a loop — got violation as expected
Verified SOQL in a method (or recursive call) invoked from a loop — got violation as expected
Verified SOQL in static helper method called from a loop — got violation as expected
Verified SOQL inside a while loop — got violation as expected
Verified SOQL inside a do-while loop — got violation as expected
Verified SOQL directly inside System.debug() within a loop — got violation as expected
No Violations Expected for the below scenarios
Verified Bulkified SOQL outside the loop (e.g., IN :ids) — no violation as expected
Verified SOQL in deep conditional logic but not inside a loop — no violation as expected
Verified SOQL inside try/catch block, not inside a loop — no violation as expected
Verified SOQL in method not called from a loop — no violation as expected
Verified SOQL inside interface/abstract method (called via polymorphism from loop) — no violation as expected
14. Verified SOQL inside constructor called from a loop — no violation (as expected for shallow analyzers)
Fixed issue regarding restricted access for CodeScan Platform Integration Users
Some users were reporting that their platform integration users has the same accessibility to CodeScan as their standard users. This issue is remediated in this release.
As a PIU (Platform Integration User) with restricted access in the CodeScan platform, PIU should only be able to view the Account section after logging in. All other features like Project Analysis, Project View, Issues View, and Search etc. (All except Account Section) should be inaccessible. Within the Account section, PIU should see the following tabs:
Profile
Security
Notifications
Projects
Organization
Additionally, the Help and Profile sections in the header should remain accessible. When clicking on the Profile icon, a pop-up should appear displaying (As shown in attached images):
Username, Email
My Account
Logout Option
Verified Restricted Access for CodeScan Platform Integration User by validating the following scenarios:
Verified all integration project analysis and PR analysis as a Standard user.
Verified all IDEs as a Platform user.
Verified IntelliJ, VS Code, GitHub Actions, SFDX, Sonar Scanner, and Azure as a Standard user.
Platform users should have access only to the My Account page.
Platform users should only be able to view the Projects and Organizations tabs—no actions should be permitted.
Both Standard and Platform users should have:
The Help section is accessible in the header.
The Profile section is accessible in the header.
On clicking the Profile icon, the Platform user should be able to see:
Username
Email
My Account
Logout option
8. Verified Billing & Revenue Compliance for both Standard and Platform users.
Users who are Standard users in some organizations and Platform Integration users in other organizations should be shown the homepage of the organizations where they are Standard users upon login.
If Standard users do not have any homepage, they should be shown the My Projects page (All Projects), which should only display projects from the organizations where they are Standard users.
User type and UI should be organization-specific. If a user switches between organizations, the UI corresponding to their user type in the selected organization should be displayed.
If Standard users do not have any homepage, they should be shown the My Issues page (All Issues), which should only display issues from the organizations where they are Standard users.
CodeScan Release 25.1.4
Release Date: 6 July 2025
Summary
CodeScan 25.1.4 is comprised of the following 6 components:
1 New Features
3 Enhancements
2 Fixes
Component details are listed in their corresponding sections within this document.
New Features
1. Support for Enterprise Git Connections / Configuring & Managing ALM Integrations
In CodeScan, Enterprise Git Connections enable organizations to securely integrate with self-hosted or enterprise instances of GitHub, GitLab, and Bitbucket. Admins can configure these connections at the organization level using OAuth credentials and define allowed IP ranges for secure access. Once connected, these integrations streamline project onboarding by allowing users to directly link Git repositories during project setup for automated analysis and CI/CD workflows.
More detailed info can be found in our Knowledge Base here:
Enhancements
1. Enhancement to CodeScan Rule “URL Redirection to Untrusted Site” {sf:OpenRedirect}
CodeScan has traditionally used this rule to check against redirects to user-controlled locations. This is important because untrusted input could cause an attacker to redirect the user to a malicious site, thereby allowing the attacker to launch a phishing scam and steal user credentials.
However, our existing rule did not specifically check for the use of Network.forwardToAuthPage.
This rule has now been enhanced with this logic, and we have verified that users are now able to see the violation for the use of both Network.forwardToAuthPage and PageReference.
More details regarding the Network class can be found here: Salesforce Developers.
1. Enhancement to CodeScan decorations of SARIF Reports
Since the 24.0.6 release (June 2024), CodeScan was enhanced to decorate standard SARIF output. While CodeScan had been able to generate SARIF output before the 24.0.6 release, it’s noteworthy to mention that the SARIF output in GitHub does not contain the severity. As such, we added severity to our SARIF output, thereby allowing CodeScan to provide a more verbose presentation of the issues in GitHub. This change has been providing a better experience for our customers working in GitHub Actions.
The way this feature was originally designed was:
When generateSarifFile: true, the generated SARIF file includes all issues, both open and resolved. Additionally, the report contains detailed metadata such as Type and Severity for each issue.
When generateSarifFile: false, the generated SARIF file includes only open issues, and it does not include the Type and Severity information for the issues.
This means that when generateSarifFile is set to false, the generated SARIF file includes only open issues, but omits important metadata such as Type and Severity for each issue.
However, to maintain consistency and support downstream analysis tools, the SARIF file should always include detailed metadata for each issue, regardless of the generateSarifFile setting.
Thus, this enhancement expands upon the existing capability and introduces much more robust functionality.
With this release, when generateSarifFile: false or generateReportFile: true, the SARIF file:
Contains only open issues respective to the branch and PR
Includes full metadata for each issue, including Type and Severity for rules and results
More detailed information can be found here: https://knowledgebase.autorabit.com/product-guides/codescan/report-and-analysis/generating-decorated-sarif-reports
Verified the below types of analyses with SARIF report all are working as expected:
Commit request analysis
PR analysis
Merge analysis
SARIF reports
Verified the SARIF report with the parameter generateSarifFile: false/true in the YML file user is able to see the open issues of the specific branch or pr and also able to see the issue TYPE and SEVERITY in the SARIF report.
2. On the Billing Page, a banner was added that details the level of access users have within the CodeScan UI based on user license type
Customers who are using a user-based license model will now have a banner on their Billing Page that provides additional clarity regarding the CodeScan features available to users based upon their license type. Standard users will have access to all CodeScan features (although access can be restricted by admin based on user privileges). Platform Integration Users will only have access to their Profile, along with access to the Security Tab and the Notifications Tab. Additionally, both types of users can fully use the CodeScan extension for VS Code and IntelliJ.
Fixes
1. Fixed issue where after a user is deactivated, the user is still displayed on Members page
Some users were reporting that after a user is deactivated, the user is still displayed on the Members page.
Detailed Solution
Made changes in the codebase to remove the user from members table when the user is deactivated.
Ensured that using “search” on the Members page, only active users are retrieved.
The user is no longer able to login via SAML
Verified the below scenarios regarding users being displayed in Members page, and all scenarios are working as expected.
Create and Activate New User: User appears under the Members list of the active organization
Add User to Inactive Organization: User is visible under the Members list of the inactive organization
Deactivate User from Instance: User no longer appears in the Members list. Behavior confirms that deactivated users are excluded from the UI display
Verify SAML Login for New User: Authentication via SAML was successful
Billing Page User Count Verification: User count reflects the new user addition appropriately. Billing data is updated as per user assignments
2. Fixed issue with codescan-scanner-action (occurring after CodeScan upgrade)
Some users were reporting that when their CodeScan project was upgraded to CodeScan 24.12.0.100206, it was incompatible with our codescan-io/codescan-scanner-action (and thus breaks customers’ GitHub Actions pipelines for pull request scanning).
This issue is remediated with this fix.
Validated that all below scenarios are working as expected.
Verified the GitHub Actions runner when using runs-on: ubuntu-latest
Verified the GitHub Actions runner when using runs-on: macos-latest
Verified the GitHub Actions runner when using runs-on: windows-latest
Verified the GitHub Actions if JRE and Sonar Scanner is not present in cache and also Verified the logs if JRE and Sonar Scanner are present in the cache.
Verified the below type of analysis (with SARIF report) are all working as expected.
Commit request analysis.
PR analysis.
Merge analysis.
SARIF reports.
Verified the SFDX analysis (with SARIF report) the analysis is successful and able to generate the SARIF file locally where user is able to see the tags, rule text, results, type of the Bug and type of the Severity.
Verified the S3 integration the analysis is successful.
Verified the CodeScan extension in the Azure DEVOPS plugin on the TEST instance working as expected.
Verified the main/default analysis which is successful.
Verified the branch analysis which is successful.
Verified the below sonar scanner versions
sonar-scanner-5.0.1.3006 - Analysis is successful
sonar-scanner-6.0.0.4432 - Analysis is successful
sonar-scanner-6.2.1.4610 - Analysis is successful
sonar-scanner-7.1.0.4889 - Analysis is not successful (threw exception; nested exception is org.bouncycastle.crypto.fips.FipsOperationError: org.bouncycastle.crypto.fips.FipsOperationError: Module checksum failed: expected)
CodeScan Release 25.1.3
Release Date: 22 June 2025
Summary:
CodeScan 25.1.3 is comprised of the following 5 components:
3 Enhancements
2 Fixes
Component details are listed in their corresponding sections within this document.
Enhancements
1. New Banner in billing when license entitlements exceeded
In this release, we created a new banner to inform admins when their licenses entitlements have been exceeded. It advises the admins to contact their account team to get their entitlements amended.
Separately, the AutoRABIT account team will be notified directly as well.
In the example shown, Customer X is licensed for 2 Platform Users, but currently have 4 Platform Users activated in their Org. As such, the banner appears to advise the admins of this discrepancy.
Additionally, this new banner is coupled with additional billing logic (detailed in the next note) aimed to ensure that user operations are not disrupted when license entitlements are exceeded, providing a better user experience for our customers.
2. New logic in billing allows users continued operations
In this release, we made an update so that users are not blocked when an organization exceeds their license entitlements. Instead, a new banner will appear on the billing page advising the admins that their license entitlements have been exceeded (see previous note above).
This feature also ensures that user operations are not disrupted when license entitlements are exceeded, providing a better user experience for our customers.
3. Project Report Status update in UI
Several customers had previously reported that on the Project Report page, the UI displays the Project Report as “stuck” in the queue. This status persists even after users receive the corresponding email notification in Outlook.
We have remediated this issue with this release by updating the status in the UI to "Your project report is currently being processed. You will receive it via email shortly."
Verified that the 4 scenarios below are working as expected
3.1 - "Verified: The updated message after enabling project reports and enabling the received scheduled reports in the CodeScan UI."
3.2 - "Verified: The updated message after enabling project reports and disabling the received scheduled reports in the CodeScan UI."
3.3 - "Verified: The updated message after disabling project reports in the CodeScan UI."
3.4 - Able to receive the project reports via email for all the above three case
Fixes
1. Fixed issue with certain menus where users were unable to easily scroll down and choose a value from the menu
Some users were reporting that they were unable to scroll down in the quality profiles section in project settings.
This issue has been remediated in this release.
The dialog box was resized.
We have verified that with this fix, users are able to scroll down in the Quality Profiles section within the Project Settings. We also verified that the dialog box is resized.
2. Fixed Deprecation Warning associated with sonar.login
Some customers were reporting that they were
receiving deprecation warnings in their scans indicating that the use of sonar.login is deprecated, and that instead, going forward, authentication should be done using sonar.token.
This issue has been remediated in this release. CodeScan now supports both sonar.login and sonar.token for authentication during Codescan analyses.
Verified the below plugins by using sonar.token and sonar.login parameters in the sonar command and sfdx; both scenarios are working as expected.
SFDX -@salesforce/cli/2.61.8
Sonar-scanner - 5.0.1.3006V
Validate Project analysis through above plugins
Validate branch analysis.
CodeScan Release 25.1.2
Release Date: June 11, 2025
Summary
CodeScan 25.1.2 is comprised of the following 19 components:
· 3 New Features
· 3 Enhancements
· 2 New Rules
· 11 Fixes
Component details are listed in their corresponding sections within this document.
New Features
1. CWE Numbers Added to Vulnerability Rule “Unescaped Value Could Cause XSS”
We have added CWE Number MITRE CWE-80 and additional CWE numbers (95 and 470) to the rule “Unescaped Value Could Cause XSS”
Verified the CWE number on the rule Unescaped Value Could Cause XSS by confirming that user is able to see the added CWE Number MITRE CWE-80 (along with additional CWE numbers 95 and 470)
Please note, these rules are only available for projects created with CodeScan's direct Salesforce integration due to being based on a direct query to a Salesforce Org.
2. Disable “Invite Members" option
Invite members is a feature in CodeScan designed for organizations using Auth0 for authentication. In contrast, it is not applicable for SSO enabled environments.
To date, SSO customers would have access to this feature, even though the functionality would not be enabled for them. We recognize that this can cause confusion and lessen the user experience. As such, we have added a new option in CodeScan allowing any organization to disable the “Invite Members” functionality in CodeScan.
Description
The "Disable Invite Members" option in Administration > Organization Settings of CodeScan allows Organization Admins to control the visibility of the "Invite Member" button. By default, the option is active or visible. When enabled, the "Invite Member" button is hidden for users, while disabling it keeps the button visible and functional.
Verified below scenarios, all are working as expected 1. An option/toggle called "Disable Invite Members" should be available in Administration > Organization Settings of CodeScan.
The default behavior of the invite member option should be active or visible.
When the toggle is enabled, the "Invite Member" button is hidden in administration module and members page
When the toggle is disabled, the "Invite Member" button remains visible and functional as usual in administration module and members page
Other functionalities related to member management (e.g., viewing members, editing permissions) should remain unaffected.
Able to invite users to the codescan organization
Restricting Platform Integration User Access for Standard Users
This feature ensures that standard users who manage user access cannot switch their role to a Platform Integration User, so that user permissions are maintained correctly.
Preventing Standard users with System Admin Permission from switching to a Platform Integration User role will reduce potential misconfigurations and ensure compliance with user access policies. To enforce this, we have implemented an alert and disabled the option in the UI. This will give administrators better control over role assignments and prevent unintended access changes.
On the Members page, the following alert "You are a System Admin. You are required to have a Standard User License.“ is displayed.
Verified the Restricting Platform Integration User Access for Standard Users via the following: 1. Verified admins are able to see the alert “You are a System Admin. You are required to have a Standard User License.“ if Standard users with System Admin Permission try switching to a Platform Integration User.
Verified admins are able to change users from standard to platform if standard user is without System Admin Permission
Verified admins are able to see the alert “You are a System Admin. You are required to have a Standard User License.“ if user is owner and trying to switch from standard to platform user
Enhancements
1. Enhanced rule “vf:AvoidJavaScriptScriptlets” by adding a new parameter to the rule
Historically, CodeScan has offered our “Avoid JavaScript Scriptlets” rule to inspect customer’s code and flag where there JavaScript Scriplets.
With this release, a new parameter was introduced to allow users to choose whether to include or ignore violations related to code supporting the Lightning functions within script.
Parameter Name: ignoreSupportingCode
Type: Boolean (true or false)
Default: false
Description: This option allows users to ignore violations related to code supporting the Lightning functions within script. By default, it is set to false.
Verified the below scenarios for rule vf:AvoidJavaScriptScriptlets and report that all scenarios are working as expected.
Validated the rule with LightningFunctions and set the default value false then user is able to see the violations.
Validated the rule with LightningFunctions and set the value true then user is not able to see the violations which is expected.
Validated the rule without LightningFunctions then user is able to see the violation which is expected.
Validated the rule by setting the parameter ignoreSupportingCode as false/true working as expected.
1. Enhanced rule “Controller Naming Convention” for Apex and Visualforce
Some customers are reporting that CodeScan is flagging violations on components that should not be flagged (i.e., SandboxRefreshAdminController)
This issue is remediated in this release.
We validated the fix by:
Creating a class file in salesforce org using UI and name the controller like in example.
Creating a vf page in salesforce org with the controller attribute like shown in the example.
Setting parameters for controller naming in CS, try the parameters with different cased letters ex: ConTroLLer etc.
After scanning false positives should not be visible
2. Updated description for Deprecated rules
Historically, CodeScan has deprecated rules over time. However, we recognize that we can be clearer about why the rule is being deprecated. In this release, we have initiated this practice (and plan to adhere to this practice in the future).
1.Update the description of deprecated Apex Rule “Use System.assertEquals instead of System.assert“ and key”sf:UseAssertEqualsInsteadOfAssertEquality” with the following:
This rule detects unit test assertions in object references equality. Instead of using System.assert combined with "==" as an equality operator, these assertions should be made by more specific methods, like assertEquals.
This rule has been deprecated, as Salesforce recommends using the Assert class for unit tests. Please remove this deprecated rule from your custom Quality Profile and instead add the rule sf:UseAreEqualInsteadOfAssertBoolean.
2.Update the description of deprecated Apex Rule “Use System.assertEquals instead of System.assert“ and key”sf:UseAssertEqualsInsteadOfAssert” with the following:
This rule detects Unit test assertions in object references equality. Instead of using System.assert combined with ".equals()" as an equality check, these assertions should be made by more specific methods, like assertEquals.
This rule has been deprecated, as Salesforce recommends using the Assert class for unit tests. Please remove this deprecated rule from your custom Quality Profile and instead add the rule sf:UseAreEqualInsteadOfIsTrue
3.Update the description of deprecated Apex Rule “Use System.Assert instead of System.assertEquals“ and key”sf:UseAssertInsteadOfAssertEquals” with the following:
When asserting a value is the same as a boolean literal, use System.assert, instead of System.assertEquals.
This rule has been deprecated, as Salesforce recommends using the Assert class for unit tests. Please remove this deprecated rule from your custom Quality Profile and instead add the rule sf:UseIsTrueInsteadOfAreEqual
4.Update the description of deprecated Apex Rule “Unnecessary Parentheses“ and key”sf:UnnecessaryParentheses” with the following:
Sometimes expressions are wrapped in unnecessary parentheses, making them look like function calls.
This rule has been deprecated. Please remove it from your custom Quality Profile and instead add the rule sf:UselessParentheses as a best practice for code styling.
New Rules
1. Server Side Request Forgery
This is a rule that checks for any changeable inputs to a url string in a method that returns a PageReference.
Type: Vulnerability Severity: Critical Name: Server Side Request Forgery (SSRF) Key: ServerSideRequestForgery Message: Sanitize input to avoid possible SSRF Description: This rule identifies potential Server-Side Request Forgery (SSRF) vulnerabilities by detecting unsafe URL construction and external network requests that could allow an attacker to manipulate server-side network calls.
Server-Side Request Forgery (SSRF) occurs when an attacker can influence the server to make arbitrary network requests, potentially accessing internal resources, sensitive endpoints, or bypassing security controls.
Input can be cleansed by using Id.valueOf, Date.valueOf, etc. Or escaped using String.escapeSingleQuotes().
Parameters Name: sanitizationMethod Description: A comma separated list of custom methods that provide input sanitization.
CWE: 918
Test Cases with Violations 1.Validated direct embedding of user input into a URL without sanitization, resulting in a violation (SSRF) as expected
2.Validated unescaped dynamic input into URL, resulting in a violation (SSRF) as expected.
3.Validated that one parameter is sanitised but the other is not sanitised, still resulting in a violation (SSRF) as expected
4.Validated concatenated unsafe dynamic parameters in a URL, resulting in a violation (SSRF) as expected.
5.Validated the presence of a malicious SSRF-style payload embedded in the URL, resulting in a violation (SSRF) as expected.
6.Validated the attempt at "sanitization" using regex, which is not an approved method, resulting in a violation (Improper sanitization) as expected
Test Cases with No Violations
1. Validated input sanitized using Id.valueOf, resulting in no violation as expected.
Validated input escaped using String.escapeSingleQuotes, resulting in no violation as expected.
Validated that the URL starts with "/" ensuring an internal redirect, resulting in no violation as expected.
Validated date validated using Date.valueOf, resulting in no violation as expected.
Validated a static URL with no dynamic input, resulting in no violation as expected.
Validated fully escaped input and use of safe methods, resulting in no violation as expected.
NOTE: The implementation currently addresses the most common scenarios related to resource injection and SSRF vulnerabilities. However, due to the dynamic and context-dependent nature of these issues—especially when influenced by external inputs, indirect references, or complex backend behaviors—there may be edge cases that are not readily identifiable or testable. These may only surface under specific configurations or data conditions.
Resource Injection
Prior to this new rule, CodeScan did not catch resource injection in Apex.
This is very similar to our new rule “Server Side Request Forgery” (also included in this release)
However, there are some basic things that make it resource injection and not SSRF.
In this example:
public PageReference init(){
AccListString = 'INIT';
BaseObjId = system.label.MY_Label;
return null;
}
public PageReference prepareAccs(){
String newUrl = '/apex/maps__Maps?baseOjectId='+BaseObjId+'&recordIds='+AccListString;
PageReference p = new PageReference(newUrl);
p.setRedirect(true);
return p;
}
Here, we are looking at resource injection because the URL is internal (starts with / )
This rule should find any external variables that are used to create dynamic internal URLs.
Acceptance Criteria
Type: Vulnerability Severity: Critical Name: Resource Injection Key: ResourceInjection Message: Sanitize input to avoid possible resource injection Description: This rule identifies potential resource injection vulnerabilities by detecting unsafe URL construction for internal network requests.
Resource injection occurs when user-controllable data is used to specify a resource identifier without proper validation.
Input can be cleansed by using Id.valueOf, Date.valueOf, etc. Or escaped using String.escapeSingleQuotes().
See:
MITRE, CWE-99 - Improper Control of Resource Identifiers ('Resource Injection')
Tags: cwe
Remediation Time: 10 minutes
Parameters: Name: sanitizationMethod Description: A comma separated list of custom methods that provide input sanitization.
CWE: 99
Verified the below scenarios are all working as expected
Verified that sanitizing both BaseObjId and AccListString before URL building prevents violations.
Verified that validating BaseObjId using Id.valueOf() ensures the ID is valid and safe to use in URLs.
Verified that input AccListString validated with regex and sanitized prevents violation.
Verified that using AccListString directly in URL without any sanitization or validation causes violations.
Verified that sanitizing only BaseObjId but not AccListString leads to a violation.
Verified that sanitizing the URL string after using variables has no effect, resulting in a violation.
Verified that URL encoding AccListString without further format validation leads to violation
Verified that replacing characters rather than proper sanitization leads to security violations.
NOTE: This implementation currently addresses the most common scenarios related to resource injection and SSRF vulnerabilities. However, due to the dynamic and context-dependent nature of these issues, specially when influenced by external inputs, indirect references, or complex backend behaviors—there may be edge cases that are not readily identifiable or testable. These may only surface under specific configurations or data conditions.
Fixes
1. Fixed issue with the CSV Export not functioning properly with all nCino projects
We detected that some nCino projects are unable to export to CSV. The issue occurs after 500 records are returned (where the request does not contain the necessary data).
This issue is remediated in this release. We verified the fix and are now able to export the issues exceeding 500 records for all ncino projects (as expected)
2. Fixed 2 issues with our SOQL Injection rule
We have discovered that the issues flagged disappear on different lines; we have also discovered that CodeScan doesn’t find the fflib method escape.
These 2 issues are remediated in this release.
3. Fixed issue with the rule “Page layout name contains special characters” (sfmeta:PageLayoutNaming)
Some customers were reporting that CodeScan was flagging that their Page layout name contains special character even though they didn't add any special characters.
This issue has been remediated in this release.
4. Fixed issue with the rule “vf:UnescapedAttributes vulnerability” {where false positive violations were being flagged}
CodeScan suggests the remediation for this issue is to use JSENCODE() to escape values. However, some customers reported that when this is added to their code, the issue was still being flagged as a violation. We validated the fix by:
Verified the updated description and example under rule: vf:UnescapedAttributes vulnerability
• Verified that Rule is throwing violation as expected
This CodeScan rule was updated with the following changes:
1. Changed the description to the following:
Reflected Cross-site Scripting (XSS) occurs when an attacker injects browser executable code within a single HTTP response.
Using unescaped parameters can be a security risk. c:* and apex:* attributes are not checked unless they are known to cause problems. You can check other attributes by adding them to the configuration for this rule.
In Visualforce, escape methods such as JSENCODE can be used to sanitize variables as shown below.
For Aura components, sepcifically aura:unescapedHtml, make sure to sanitize variables in controllers before using them. This component is intended to output properly sanitized HTML from a trusted source. If properly handled, mark the issue as Resolved: False Positive/Won't Fix.
2. Added the following Aura Example Bad Scenario:
Example :
<aura:component>
<aura:unescapedHtml value="{!v.htmlstring}"/>. //Bad: not recommended.
</aura:component>
5. Fixed issue with the rule “Open Redirect” (sfmeta:PageLayoutNaming) {where false positive violations were being flagged}
Some customers reported that our current rule does not handle the use of “Network.forwardToAuthPage”
We remediated this issue and validated that CodeScan now throws a violation in both of these cases.
Verified the rule “Open Redirect” by validating:
Users are able to see the violation for the use of both Network.forwardToAuthPage and PageReference
More info regarding “Network class” can be found here:
Network Class | Apex Reference Guide | Salesforce Developers
Fixed issue with the rule “Field Level Security Vulnerabilities” (sfmeta:PageLayoutNaming) for classes using “Without Sharing” {where false positive violations were being flagged}
Some customers have reported an issue with CodeScan's reporting of "Permissions should be checked before accessing resource" vulnerabilities in our Apex codebase, specifically within classes that are declared without sharing.
The without sharing keyword in Apex classes causes the code to execute in system context, bypassing standard Salesforce sharing and field-level security checks. This is intentional for certain system-level operations and utility classes within our application.
However, CodeScan is flagging fields within these without sharing classes as vulnerabilities, stating "Permissions should be checked before accessing resource." This is creating an inflated number of false positives and incorrectly portraying our code's security posture.
CodeScan is designed to identify potential security issues; however, in the context of without sharing classes, these field-level security checks are redundant and misleading.
As such, the rule update in this release enables CodeScan to recognize that when a class is declared without sharing, field-level security checks are irrelevant, and the "Permissions should be checked before accessing resource" rule is suppressed for fields within without sharing classes.
Note that a new parameter has been added to this rule to Ignore Without Sharing
Name: ignoreWithoutSharing Message: When this parameter is true, this rule ignores Field Level Security issues in all without sharing classes. Default: false
Appropriately, CodeScan is flagging violations properly when “with sharing” is used.
Fixed issue with CodeScan’s APEX parser
Some customers reported that the CodeScan parser was incorrectly flagging valid Apex code using the UPDATE AS SYSTEM syntax as a parsing error. This was occurring because the parser doesn't recognize the AS SYSTEM portion of the UPDATE statement, leading to a ParseException and preventing accurate code analysis.
This issue has been remediated with this release.
We had previously verified the Parsing error in APEX Code for DML queries if user using UPDATE AS SYSTEM syntax would throw the parser exception. With this fix, users are now able to see the violations as expected for the file.
Verified the below queries in Apex code that users do not get any Parser errors; instead the updated CodeScan parser is working as expected.
INSERT AS SYSTEM
DELETE AS SYSTEM
UNDELETE AS SYSTEM
UPDATE AS SYSTEM
Fixed issue with rule “Avoid running Soql and DML inside loops” {sf:AvoidSoqlInLoops}
Some customers reported unexpected behavior in this rule, producing false positives.
The root cause of the false positives is that when a method of an object is invoked within another method, and both methods share the same name, the current rule implementation incorrectly interprets this as a recursive call and subsequently triggers a violation. Further, the Stack Loop trace is indefinite.
This has been remediated in this release. The updated rule logic now handles these edge cases by checking for method image to be exactly the same (method != diffObj.method).
We have verified the fix across related and existing test cases and edge conditions by confirming that if a method of an object is invoked within another method, and both methods share the same name, the user will not see the violation (as it is false positive).
Fixed issue with rule “RequireDescriptionComponent”
Some customers reported that the CodeScan rule “RequireDescriptionComponent” rule was not working for custom fields on standard objects.
This issue has been remediated in this release. Previously, CodeScan offered a rule “sfmeta:RequireDescriptionField” which had been deprecated for this updated rule. But the updated rule was not designed for standard objects. When we tested the logic of the deprecated rule, we found that it could be used for reference for this update to the new rule “RequireDescriptionComponent”
The rule enhancement was verified via the below scenarios 1. Verified Custom Field on Standard Object – Missing Description
Verified Custom Field on Custom Object – Missing Description
Verified Standard Fields on Standard Object – Missing Description
Verified Custom Field on Standard Object – With Description
Verified Custom Field( With Description) on Custom Object (Without description)
10. Fixed issue with rule “sf: FieldLevelSecurityRule”
During maintenance testing, we discovered that this rule was triggering the null pointer exception when parsed through the trigger files. In the rule logic it was searching for relevant ASTClassOrInterfaceBody to get all the constructors in that class. Since triggers don't have constructors, control flow proceeds further if we get a non-null node for ASTClassOrInterfaceBody. We updated this rule to parse the trigger files by adding extra logic to find the Trigger specific nodes (TriggerBodyDeclaration etc).
We tested the fix to the Null pointer Exception with sf: FieldLevelSecurityRule and verified we are now no longer able to see the Null pointer exception for the trigger files in the logs (as expected).
11. Fixed issue with Organization images displaying as large icons in the org list
CodeScan has historically allowed images to be added under Organization settings by our customers. These images are then displayed on the organization home page and in the Org list.
After we released CodeScan 25.1.0 (April 2025), customers org icon images could appear as large icons. This issue was remediated in this release by restricting the size of the image on the Org page to the size of a usual non-image icon (around 30px).
We have verified the Organization image is now restricted in size, and users are able to see the image as expected.
CodeScan Release 25.1.1
Release Date: May 11, 2025
Summary
CodeScan 25.1.1 is comprised of the following 3 components:
3 Fixes
Component details are listed in their corresponding sections within this document.
New Features
There are no New Features associated with this release
Enhancements
There are no Enhancements associated with this release
New Rules
There are no New Rules associated with this release
Fixes
Fixed an issue with rule tags blocking analyses
Several customers reported that, after the recent CodeScan upgrade to 25.1.0, some of their analyses were not properly executing. We uncovered that this was due to new logic added to a database table. This fix corrects this issue and will allow all blocked analyses to run properly.
We have verified the below scenarios and report that all are working as expected.
Tags which are system default
Tags which are not system default
Custom tags
Verified the vf:exception and sf:exception rule by adding tags in one organization and seeing the analysis working without any issue in that org or any other org.
Verified the analysis for the rule sf:exception by assigning the tags. Confirmed analysis was successful and that users are able to see the assigned tags in the issues page.
Verified the analysis when the tags are not assigned. If there are any new violations the user is unable to see any tags for the violations (which is expected).
Fixed Error: [CS] API GET status code: 404 when users try to generate Sarif File on their environment
Several customers reported the following error “Error: [CS] API GET status code: 404 “when users try to generate Sarif File on their environment.
This fix corrects this issue and will allow users to generate Sarif files on their environment.
We have verified the below scenarios for GitHub Actions SARIF report on TEST environment and are able to generate SARIF reports successfully.
Analysis is getting “success” and able to get the SARIF report where the results are same in the report and on CodeScan UI
Validated the Pull request analysis in GitHub actions we are able see that the PR analysis is happening for the changed files.
Validated the Commit request analysis.
Validated the PR analysis.
Validated Merge analysis.
Fixed Error: [CS] API GET status code: 404 when users try to generate Sarif File on their environment
After the upgrade to 25.1.0, we uncovered 2 minor issues:
The IDP group mapping feature flag was not working as expected.
If an ID user is member of org 1 and owner of org 2, then from org2 SAML connection she was able to make anyone an owner of org1.
This update remediates these 2 issues.
Verified the IDP Group Mapping flag by Enabling and Disabling the instance is now working as expected.
Release Notes 25.1.0
Release Date: 20 April 2025
Summary
CodeScan 25.1.0 is comprised of three main components / features:
Component details are listed in their corresponding sections within this document.
New User Interface
In this release, we have updated the CodeScan User Interface order to provide four key benefits:
Easier navigation, which provides both an improved, intuitive experience for more advanced users, while reducing the learning curve for new users
Consistency in screen layout, providing a more cohesive experience throughout the application
Enhanced performance and responsiveness within CodeScan
Brand modernization alignment with other AutoRABIT solutions
Technical Architecture Improvements
The CodeScan 25.1.0 contains various technical architecture improvements and upgrades to various libraries. We have also included several enhancements to CodeScan’s security architecture.
Fixes
Fixed a false positive in the 'sf:AvoidGlobalModifier' rule. The violation is now ignored for global classes used as return types in any global static method.
Last updated
Was this helpful?