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
CodeScan Release 25.1.17
Release Date: 04 January 2026
Summary
CodeScan 25.1.17 is comprised of the following 5 components:
2 New Features
3 Rule Enhancements
1 Fix
Component details are listed in their corresponding sections within this document.
New Features
1. Data Flow Analysis
CodeScan has implanted new logic in some of our rules that detect vulnerabilities. This advanced logic provides precise visibility into where unsafe data originates and how it propagates, helping developers fix vulnerabilities at their source rather than applying superficial patches at the output stage.
In this first release, we have added this advanced “source to sink” logic in 3 rules:
Unescaped Error Message XSS {Rule ID: sf:UnescapedOutput}
URL Parameters should be Escaped/Sanitized {Rule ID: sf:UnescapedSource}
Avoid Calling SOQL and DML Inside Loops {Rule ID: sf:AvoidSoqlInLoops}
You can find specific details about each of these rules in the “Rule Enhancements” section of these release notes.
2. COMING SOON: New GitLeaks Rules in CodeScan
CodeScan has implanted new logic within the Rules Engine that can detect GitLeaks vulnerabilities. GitLeaks is a tool for detecting secrets like passwords, API keys, and tokens. We have extended this logic to cover Salesforce specific languages and components including:
GitLeaks Secret Detection in Apex source files
GitLeaks Secret Detection in Salesforce Metadata Files
GitLeaks Secret Detection in Visualforce & Lightning Files
Please note that these rules are not yet available for your scans (but will be available soon). However, these rules are now visible within your CodeScan orgs so that you can begin planning and reviewing for incorporation within your analyses once fully available.
We will provide detailed rule descriptions with the NEW RULES section of the corresponding release notes once they become generally available for use.
Description
Implement a GitLeaks rule that triggers scans specifically on Salesforce files, so that all standard and custom GitLeaks rules (e.g., AWS keys, OAuth tokens, passwords, PEM files) are applied to these files, and any detected issues are surfaced directly in CodeScan>Issues.
Implementing GitLeaks rules within CodeScan provides tremendous value to our customers, enabling them to automatically scan Salesforce files and ensure:
Any secrets or sensitive credentials hardcoded in Apex classes or triggers(*.cls, *.trigger), Visualforce pages, Lightning components, etc. will be detected early.
Developers will see security issues integrated into their existing CodeScan reports without needing to run GitLeaks separately.
Value / Purpose
Security Guardrail: Prevents exposure of secrets in Salesforce code (API tokens, passwords, OAuth client secrets).
Compliance & Governance: Helps organizations enforce security best practices and avoid regulatory violations due to hardcoded secrets.
Summary
These rules run GitLeaks on Salesforce source files to detect hardcoded secrets such as API keys, passwords, OAuth tokens, and private keys. All standard and custom GitLeaks rules are applied, and detected issues are surfaced in CodeScan.
Rule Enhancements
1. Updated the Apex rule “Unescaped Error Message XSS” to include data flow analysis logic {Rule ID: sf:UnescapedOutput}
Description
1. Reimplement the sf:UnescapedOutput rule to include data flow tracing for variables passed to addError() (e.g., addError(html, false)).
This will determine whether variables originate from unsanitized sources by tracing them across methods and assignments. Use UrlSanitizationRule logic as reference for tracking unescaped values.
2. Update the issue description to include the exact source variable and its data path before being rendered.
Hypothesis If we trace the data flow from unescaped or unsanitized sources to the point of output in addError, developers can clearly see how unsafe data reaches the output layer, making the issue more actionable.
Value/Purpose Provides precise visibility into where unsafe data originates and how it propagates, helping developers fix vulnerabilities at their source rather than applying superficial patches at the output stage.
Verified the data flow tracking logic for unescaped output in Apex is working and the updated description has been applied.
2. Updated the Apex rule “URL Parameters should be Escaped/Sanitized” to include data flow analysis logic {Rule ID: sf:UnescapedSource}
Description
1. Extend the sf:UnescapedSource rule to track the flow of URL parameters retrieved from ApexPages.currentPage().getParameters().get(...). The data flow analysis will identify whether these variables are properly sanitized or escaped before reaching any sensitive sink or being rendered.
2. Update issue descriptions to show both the untrusted source and its usage path.
Hypothesis If the system highlights the full journey of parameters from getParameters() to their usage points, developers will better understand how unescaped data can lead to vulnerabilities and where sanitization is missing.
Value/Purpose Enables developers to pinpoint missing sanitization in their Apex controllers by visualizing data flow paths, thus improving the security posture of Visualforce and Lightning pages.
Acceptance Criteria
Existing Message: URL parameters should be escaped/sanitized XSS
Updated Message: URL parameters should be escaped/sanitized XSS. Data Flow Trace -
DECLARATION (ClassAbc.Foo line: 3)
The rule behavior was validated by testing multiple scenarios involving URL parameters retrieved using ApexPages.currentPage().getParameters().get(...). on Preview Instance.
Verified scenarios:
Usage after type validation with Integer.valueOf() — no violation raised (expected behavior).
Direct usage of URL parameters without sanitization — violation raised.
Propagation of URL parameters through variable assignment without sanitization — violation raised.
Passing URL parameters through multiple methods without sanitization — violation raised with correct data flow trace.
Usage of URL parameters in dynamic SOQL without sanitization — violation raised.
For all violating cases, the rule correctly reported the issue with an appropriate data flow trace (e.g., declaration point and usage path). The observed results match the expected behavior.
3. Updated the Apex rule “Avoid Calling SOQL and DML Inside Loops” message to include detailed data flow analysis logic {Rule ID: sf:AvoidSoqlInLoops}
Description
Refine the issue message for sf:AvoidSoqlInLoops to clearly identify the loop structure and the query being executed inside it. Include variable references and contextual flow details showing how data or parameters within the loop lead to repeated queries.
Hypothesis Providing contextual information about where and how SOQL queries are invoked within loops will improve developer understanding and reduce rework in optimizing code performance.
Value/Purpose Enhances readability and educational value of performance warnings by showing contextual flow, helping developers refactor code more efficiently.
Acceptance Criteria
Existing Message:
Avoid running SOQL and DML inside loops. Loop Trace : CaseProcessor.fetchOwnerDetails: line 16 --> CaseProcessor.processCase: line 11 --> CaseProcessor.processAllCases: line 6
Updated Message:
Avoid Running Soql and DML inside loops. Data Flow Trace -
SOQL (CaseProcessor.fetchOwnerDetails: line 16) -->
CALL (CaseProcessor.processCase: line 11) -->
LOOP (CaseProcessor.processAllCases: line 6)
Executed the following scenarios and validated that the advanced logic is working as expected.
Verified the updated behavior of the sf:AvoidSoqlInLoops rule.
Multi-hop scenarios (loop → method → method → SOQL) correctly show the full Data Flow Trace with SOQL → CALL → LOOP.
Direct SOQL-in-loop scenarios correctly show the simplified message, which is the expected behavior.
Fixes
Improved License Limit Enforcement: When a customer exceeds their licensed limits, CodeScan will no longer block access to the platform or restrict any previously licensed features. Customers can continue to use all features they are entitled to without interruption, ensuring uninterrupted workflows while they address licensing limits.
CodeScan Release 25.1.16
Release Date: 14 December 2025
Summary
CodeScan 25.1.16 is comprised of the following 4 components:
2 Rule Enhancements
2 Fixes
Component details are listed in their corresponding sections within this document.
Rule Enhancements
1. Updated the description in the CodeScan APEX rule “Server Side Request Forgery (SSRF)”
{Rule ID: sf: ServerSideRequestForgery}
Description:
Update the issue description for the sf:ServerSideRequestForgery rule to include data flow information once tracking is implemented.
Highlight how untrusted user input influences outbound requests or endpoint URLs used in HttpRequest.setEndpoint() or similar methods.
Hypothesis: Providing a traceable flow from input source to request endpoint will help developers clearly identify unsafe URL usage leading to SSRF vulnerabilities.
Value/Purpose: Improves clarity and helps prioritize high-risk SSRF issues by showing the complete journey of untrusted data to outbound request logic.
Code Example:
Existing Message:
Sanitize input to avoid possible SSRF. Data Flow Trace: Negative.otherMethod: line 4
Updated Message:
Sanitize input to avoid possible SSRF. Data Flow Trace -
CALL (Negative.otherMethod: line 4)
Make sure to check for internal methods also (E.g. FirstName variable on line 8 if used in the set endpoint call on line 11)
2. Updated the description in the CodeScan APEX rule “Resource Injection” to account detection with Source-to-Sink Tracing {Rule ID: sf: ResourceInjection}
Description:
Update the issue description for sf:ResourceInjection to display how untrusted input propagates to resource-loading statements, such as dynamic resource identifiers or file references. The new description should include the identified source and sink with a trace of intermediate transformations.
Hypothesis: If developers can visualize which variable or parameter is used to form a resource path without sanitization, they will better understand the exploit path and fix it faster.
Value/Purpose: Increases the usability and accuracy of Resource Injection findings by offering transparent, contextual information about the data flow chain.
Acceptance Criteria
Sanitize input to avoid possible resource injection. Data Flow Trace : {Class.method}: line {line number} --> {Class.method}: line {line number}
Example:
Sanitize input to avoid possible resource injection. Data Flow Trace : APIVersionsRetiredTrigger.processOldAPIVersionReferences: line 88 --> APIVersionsRetiredTrigger.processOldAPIVersionReferences: line 92
Code Example:
Existing Message:
Sanitize input to avoid possible resource injection. Data Flow Trace: Negative.otherMethod: line 4
Updated Message:
Sanitize input to avoid possible resource injection. Data Flow Trace -
CALL (Negative.otherMethod: line 4)
Make sure to check for internal methods also (e.g., FirstName variable on line 8 if used in the set endpoint call on line 11)
Rule Deprecations
There are no Rule Deprecations in this release.
Fixes
1. Fixed an issue in the APEX rule “Field Level Security Vulnerabilities”
{Rule ID: sf:FieldLevelSecurity}
Several customers reported that they were receiving the error message “Permissions should be checked before accessing resource SObject” even though they were providing suitable permissions using DML and/or SOQL statements. It was determined that CodeScan was not recognizing both DML and SOQL statements. As such, we overhauled the rule logic to address this issue and have ensured that CodeScan is now recognizing the AccessLevel.* commands in DML calls.
We have validated this new logic and verified that no vulnerabilities were raised (which is the expected and correct behavior for this updated rule logic).
2. Fixed an issue in the APEX rule “Resource Injection”
{Rule ID: sf: ResourceInjection}
Resource injections occur when user-controllable data is used to specify a resource identifier without proper validation. This rule identifies potential resource injection vulnerabilities by detecting unsafe URL construction for internal network requests. Input can be cleansed by using Id.valueOf, Date.valueOf, etc. Or escaped using String.escapeSingleQuotes().
However, several customers reported that this rule was firing improperly, even when the recommended methods have been applied. After reviewing, we confirmed cases of false positives and determined that the rule required a minor update to the rule logic.
We verified the new logic and validated that the rule is now working as originally designed.
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)
john.doe@company.com
test.user@example.test
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
Logs
System.debug('Email: jane@corp.com')
System.debug('Email: [REDACTED]')
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).
NOTE: To fully maximize the value of these rules, you can also configure them to include custom fields as parameters (e.g., SSN, Social_Security_Number, Credit_Card, Passport).
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.
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.
Note: The update has been refined to cover all scenarios—we’ve implemented logic to trigger violations for all getter method cases where there is no permission check, SOQL, or DML operation and removed the previous conditional checks. As a result, violations will now be raised for every return type except void (since it doesn’t return any value). Please note that, due to these rule changes, there may be a slight increase/decrease in reported issues for the FLS rule.
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.
Note: For more information, please refer to Michele Lanza and Radu Marinescu. Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems {Springer, Berlin, 1 edition, October 2006. Page 80}.
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.
Note: This soft deletion is triggered (and subsequently put into this disabled state) whether deleted by an org Admin OR platform-level Admin.
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.
Note: Instance-level Admins and Org Admins (customers) are able to manage deleted organizations in a dedicated “Deleted Orgs” section, so they can view and restore them within a 30-day grace period.
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.
NOTE: If we cannot update dynamically, CodeScan will use the following generic text: “Connects to your Salesforce instance or Repository to execute a CodeScan analysis.”
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.
NOTE: This feature is only available to customers who have a dedicated instance. It is not available for customers who are deployed on our SaaS multi-tenant instances.
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.
NOTE: This feature needs to be enabled in customers’ organizations. It is NOT available by default
NOTE: This feature is only available to customers who have a dedicated Instance. It is not available for customers who are deployed on our SaaS multi-tenant instances.
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