Cloud Release Notes 26.0
CodeScan Release Notes 26.0.20
Release Date: 6 September 2026
Summary
CodeScan 26.0.20 is comprised of the following components:
0 New Features
1 Application Enhancement
0 New Rules
0 Rule Enhancements
0 Rule Deprecations
2 Fixes
Component details are listed in their corresponding sections within this document.
New Features
There are no New Features in this release.
Application Enhancements
AI Code Assistant Prompt Quality Improvement
Improved AI CodeFix prompts to prevent the LLM from injecting prose, reasoning, or explanatory text into the generated code output. The worker expects only the fixed code from the AI model, but in some cases the model would include its reasoning alongside the code, which could get merged into the fixed file as if it were source code.
Behavior
Prompts have been tightened to instruct the model to return code-only output without explanatory text.
Reduces cases where AI-generated fixes contain non-code content that could break compilation.
Outcome
Improves the reliability of AI-generated code fixes.
Reduces manual cleanup of AI output before Pull Request creation.
Fixes
Username Whitespace Validation on Signup
Fixed an issue where users could sign up by entering only whitespace characters in the Username field. Although the field is required, the validation did not prevent whitespace-only values in production instances.
Behavior
Username validation now rejects whitespace-only input during signup.
Consistent behavior is enforced across all environments.
Outcome
Prevents creation of user accounts with invalid, whitespace-only usernames.
Ensures consistent signup validation across production and lower environments.
New Code Highlighting Accuracy for Salesforce Metadata
Resolved an issue where new code highlighting could misalign with the actual changed lines in Salesforce metadata files during Pull Request analysis. When an object permission block was added, the system would incorrectly display new code markers on other, unchanged object permission blocks.
Behavior
Diff generation for Salesforce metadata files (
.sfmeta) now uses native Git CLI instead of the JGit Myers diff algorithm, which produces more accurate line-level change detection for structured XML metadata.Apex classes (
.cls) and Visualforce pages (.vf) continue to use the existing diff method.The Git CLI diff mode is controlled by a feature flag that can be toggled per project.
Outcome
Eliminates false new code highlighting on unchanged metadata blocks.
Improves accuracy of PR-based analysis results for Salesforce metadata files.
Ensures reported violations align with the actual changed lines.
CodeScan Release Notes 26.0.19
Release Date: 23 August 2026
Summary
CodeScan 26.0.19 is comprised of the following components:
1 New Feature
0 Application Enhancements
0 New Rules
0 Rule Enhancements
0 Rule Deprecations
0 Fixes
Component details are listed in their corresponding sections within this document.
New Features
1. Self-Service Trial Experience (PLG)
Added a self-service trial experience that allows new users to sign up for a time-limited CodeScan trial directly from a dedicated trial URL, without requiring manual provisioning or sales involvement.
Signup Flow
A dedicated trial signup URL routes new users through Auth0 Universal Login.
Personal email domains (e.g., gmail, hotmail, etc.) are blocked via Auth0 validation rules.
Upon successful signup and email verification, a trial organization is automatically provisioned, and the user is assigned as Org Admin.
Signup information (e.g., name, email, company, phone) is sent to Salesforce to create a lead with source "CodeScan Cloud Trial."
Users must accept the AutoRABIT EULA during signup via a required checkbox, followed by an in-app EULA acceptance pop-up upon first login.
Trial Organization Configuration
Trial organizations are provisioned with configurable constraints:
Default duration: 14 days
Default maximum users: 3
Trial settings are configurable at the instance level by super admins through the Billing page:
Trial duration (in weeks)
Integration user count
Standard user count
Feature/plugin access toggles
Trial organizations do not have access to nCino, Audit Logging, MuleSoft, or AI features by default.
Salesforce integration is disabled for trial organizations—the Salesforce project type is removed from the Create Project dialog, and the Salesforce Connections administration menu is hidden.
The Billing page is hidden for non-root users in trial organizations.
Trial User Experience
A persistent banner at the top of the screen displays the remaining trial time ("Trial - X days left" or "Trial - ends today").
Users can invite others to their trial organization. Invited users are added to the inviting organization only — no personal organizations are created for invited users.
User licensing limits (standard and platform users) are enforced during invitations and member management.
Trial Expiry & Cleanup
Automated email notifications are sent at three milestones:
7 days before trial expiration
1 day before trial expiration
On the day the trial ends
After the trial period ends, the organization is archived for 30 days, then permanently deleted.
Trial users are permanently disabled after cleanup. Their email addresses are stored to prevent re-creation of trial accounts using the same email.
Outcome
Enables product-led growth by removing friction from the trial onboarding process.
Provides configurable, time-limited trial access with clear expiry communication.
Prevents the platform performance issues previously caused by mass personal organization creation.
CodeScan Release Notes 26.0.18
Release Date: 16 August 2026
Summary
CodeScan 26.0.18 is comprised of the following components:
0 New Features
0 Application Enhancements
0 New Rules
0 Rule Enhancements
0 Rule Deprecations
1 Fix
Component details are listed in their corresponding sections within this document.
Fix
1. GitHub App Authentication and Token Refresh Improvements
Resolved multiple issues where GitHub App integration analyses would fail with authentication errors after the initial access token expired, affecting both Pull Request analysis and manual analysis runs.
a. Unauthorized Status After 24 Hours
Fixed an issue where GitHub Pull Request analysis reported "Unauthorized" status with "Bad credentials" (HTTP 401) errors when analyses were triggered more than 24 hours after the initial GitHub App connection. Re-creating the GitHub App temporarily resolved the issue, but the failure would recur.
b. Refresh Token Expiry After ~8 Hours
Fixed an issue where both Manual Analysis and Pull Request Analysis failed with "The refresh token passed is incorrect or expired" after approximately 8 hours following a successful analysis. The access token refresh mechanism has been corrected to automatically obtain new tokens when existing tokens expire.
Outcome
Restores reliable, long-running GitHub App integration without requiring re-authorization.
Ensures consistent authentication for both Pull Request and manual analyses regardless of elapsed time.
Eliminates the need to re-create GitHub App connections as a workaround.
CodeScan Release Notes 26.0.17
Release Date: 2 August 2026
Summary
AutoRABIT CodeScan 26.0.17 is comprised of the following 3 components:
3 New Features
0 Application Enhancements
0 New Rules
0 Rule Enhancements
0 Rule Deprecations
0 Fixes
Component details are listed in their corresponding sections within this document.
New Features
AI Code Assistant (Pilot)
Introducing the AI Code Assistant: an AI-powered code remediation capability built directly into CodeScan. The AI Code Assistant can generate fixes for common Apex rule violations, present changes in a side-by-side diff view for your review, and deliver approved fixes through automatically created Pull Requests.
AI Credits, Usage Monitoring & Billing
Added AI credit management capabilities to support AI features consumption tracking and governance.
Key highlights:
AI credits integrated with subscription billing for accurate consumption tracking
Real-time AI usage indicator in the top navigation bar with color-coded thresholds (Healthy, Low, Critical) and hover tooltip showing exact credit counts
New AI Billing administration page (Administration → AI Billing) with a summary bar and searchable per-user consumption table with color-coded progress bars
Organization-level daily execution limits with clear notifications when limits are reached
Bulk assignment governance — maximum 10 issues per bulk action
CodeScan MCP (Pilot)
Introducing the CodeScan MCP Server: a hosted endpoint that brings CodeScan analysis data directly into the AI coding assistants developers already use, such as GitHub Copilot, Cursor, and Claude Desktop.
Once connected, you can stay in your editor and query CodeScan conversationally:
Check which projects are passing or failing their quality gate
Drill into issues, security hotspots, rules, and measures without opening the web UI
Look up organizations, projects, branches, pull requests, and analysis job details as you code
Pull CodeScan data into your own reporting or review workflow on demand
CodeScan Release Notes 26.0.16
Release Date: 19 July 2026
Summary
AutoRABIT CodeScan 26.0.16 is comprised of the following 4 components:
0 New Features
1 Application Enhancement
0 New Rules
0 Rule Enhancements
0 Rule Deprecations
3 Fixes
Component details are listed in their corresponding sections within this document.
Application Enhancements
Added Support for Salesforce Refresh Token Rotation (RTR)
Enhanced the Salesforce integration to support Refresh Token Rotation (RTR) for OAuth authentication.
Salesforce now enables Refresh Token Rotation by default for newly created External Client Applications (ECAs). With RTR enabled, refresh tokens are rotated after use instead of remaining static. This enhancement updates the CodeScan Salesforce integration to correctly manage rotating refresh tokens, ensuring uninterrupted authentication for new and existing Salesforce connections.
Behavior
The Salesforce integration now:
Supports refresh token rotation for OAuth-based Salesforce connections.
Automatically manages refresh token updates during token renewal.
Maintains connection health across successive token refresh cycles.
Supports both RTR-enabled and non-RTR Salesforce External Client Applications.
Continues to use existing authentication flows for previously configured Salesforce connections.
Compatibility Improvements
The enhancement provides compatibility with:
Salesforce Production organizations
Salesforce Sandbox organizations
Newly created External Client Applications with Refresh Token Rotation enabled
Existing External Client Applications with Refresh Token Rotation disabled
Support is available across Salesforce analysis workflows, including:
Main branch analysis
Comparison branch analysis
Scheduled analyses
Outcome
Ensures compatibility with Salesforce's latest OAuth security model.
Prevents unnecessary reauthorization for long-lived Salesforce connections.
Improves the reliability of Salesforce project analysis across repeated authentication cycles.
Maintains backward compatibility with existing Salesforce integrations while supporting new Salesforce security defaults.
Fixes
Improved SOQL in Loops Rule Accuracy
Resolved an issue where the Avoid SOQL in Loops rule (sf:AvoidSoqlInLoops) could incorrectly report violations for certain method invocation patterns, resulting in false positives.
Previously, the rule could identify SOQL or DML operations as being executed within a loop based solely on nested method call analysis, even when the queried method was not actually invoked from a looping execution path. In some scenarios, method calls originating from Apex test classes could also be included in the analysis, contributing to incorrect findings.
Behavior
The rule has been enhanced to improve analysis accuracy by validating the actual execution path before reporting nested-call violations.
Improvements include:
Reduced false positives for SOQL and DML operations that are not executed within loop constructs.
Improved evaluation of nested method invocation chains.
Improved validation to ensure nested-call violations are reported only when a genuine loop execution path exists.
Improved Diagnostics
The rule now provides more accurate reporting by distinguishing between nested method calls and actual SOQL/DML execution within loops, reducing misleading violations for valid code.
Outcome
Reduces false positives reported by the Avoid SOQL in Loops rule.
Improves accuracy of data flow and nested-call analysis.
Provides developers with more reliable and actionable rule findings.
Improves confidence in SOQL and DML loop detection for complex Apex applications.
Clarified Configuration Limits for SOQL/DML Inside Loops Rule
Updated the documentation for the Avoid SOQL/DML Inside Loops rule (sf:AvoidSoqlInLoops) to clearly communicate the supported configuration limits for method traversal depth.
Previously, the rule parameter documentation did not specify the recommended maximum value for the maxMethodTraversalDepth parameter, which could lead to unsupported or excessive configuration values being entered.
Documentation Improvements
The parameter description has been updated to clearly indicate the supported range for method traversal depth, helping administrators configure the rule appropriately.
The updated default guidance:
MaxMethodTraversalDepth = 5
MaxMethodVisitedCount = 200
Outcome
Provides clearer guidance for configuring method traversal depth.
Helps administrators understand the recommended operating limits for the rule.
Improves usability of Quality Profile configuration.
Reduces the likelihood of unsupported rule parameter configurations.
Updated Guidance for Custom Field Requirement Configuration Rule
Updated the documentation and messaging for the Custom Field Security in Standard Object rule (sfmeta:CustomFieldSecurityInStandardObject) to provide clearer guidance on the recommended approach for configuring required custom fields on Salesforce standard and shared objects.
Previously, the rule messaging did not clearly explain why marking custom fields as required at the schema level could have unintended consequences across different data entry mechanisms.
The following rule metadata has been updated:
Title: Use the Page Layout to mark the custom field as required.
Message: Use the Page Layout to mark the custom field as required.
Description: Expanded to clarify that custom fields on standard and shared objects should be marked as required through page layouts rather than at the schema (system) level.
The updated guidance explains that using page layouts limits the requirement to users interacting through the Salesforce UI, while avoiding unintended impacts on other data entry points, such as:
APIs
Data Loader
Apex
Integrations
Outcome
Provides clearer remediation guidance for Salesforce administrators.
Encourages Salesforce best practices for configuring required custom fields.
Helps prevent unintended validation issues across integrations and automated processes.
Improves the usability and clarity of rule findings.
CodeScan Release Notes 26.0.15
Release Date: 05 July 2026
Summary
CodeScan 26.0.15 is comprised of the following 5 components:
1 New Feature
1 New Rule
1 Rule Enhancement
2 Fixes
Component details are listed in their corresponding sections within this document.
New Features
CodeScan now has “salesforce-project-only” tags for Rules with SF queries
Description
Several CodeScan rules perform queries directly against Salesforce to execute their analysis. These rules require an active Salesforce project connection and cannot be used in a standard static analysis context. To improve discoverability and filterability, the tag salesforce-project-only should be added to each of these rules.
The following rules require this tag:
sfmeta:NcinoDuplicateLabels
sfmeta:NcinoComponentNamingDuplicate
sfmeta:NcinoIntUserConfig
sfmeta:NcinoDeprecatedFields
sfmeta:NcinoDuplicateLookupKeys
sfmeta:NcinoFeeTemplateScreenSection
sfmeta:NcinoNullLookupKeys
sfmeta:NcinoProductFeatureNotExist
sfmeta:NcinoProductFeatureSharing
sfmeta:NcinoNullCollateral
sfmeta:ExcessivePageLayout
sfmeta:CheckSystemAdministrator
sfmeta:CustomProfilesPermission
Value
Users working in non-Salesforce-connected environments are exposed to rules that will never produce valid results for their project type. By tagging these rules with salesforce-project-only, users can quickly filter them in or out of their rule sets, reducing noise and improving the overall rule browsing experience. It also makes it clearer to new users why certain rules may not be firing.
Acceptance Criteria
The tag salesforce-project-only is added to all 13 rules listed above.
The tag appears on the rule detail page for each affected rule in the CodeScan UI.
Users can filter the rules list by the tag salesforce-project-only and only the 13 listed rules (and any others previously tagged) are returned.
No existing tags on any of the affected rules are removed or modified.
The tag is consistent in formatting (lowercase, hyphenated) with salesforce-project-only across all rules.
A smoke test has been performed to confirm the tag is visible and filterable in a non-production environment before release.
We have verified that the tag "salesforce-project-only" has been added to all 13 rules, and that the tag is visible, consistent, and filterable in the CodeScan UI.
Test Scenarios Validated:
1: Tag presence — All 13 rules have "salesforce-project-only" tag
sfmeta:NcinoDuplicateLabels
sfmeta:NcinoComponentNamingDuplicate
sfmeta:NcinoIntUserConfig
sfmeta:NcinoDeprecatedFields
sfmeta:NcinoDuplicateLookupKeys
sfmeta:NcinoFeeTemplateScreenSection
sfmeta:NcinoNullLookupKeys
sfmeta:NcinoProductFeatureNotExist
sfmeta:NcinoProductFeatureSharing
sfmeta:NcinoNullCollateral
sfmeta:ExcessivePageLayout
sfmeta:CheckSystemAdministrator
sfmeta:CustomProfilesPermission
2: Tag visible on rule detail page for each affected rule
3: Filter by "salesforce-project-only" returns all 13 rules
4: No existing tags removed or modified on any of the 13 rules
5: Issue got triggered for a random rule, working as expected. Hence closing this user story.
New Rules
New CodeScan Metadata Rule: “Communities With Guest Access”
{Rule ID: sfmeta:CommunityGuestUserAccess"}
Description
Identify Salesforce Experience Cloud communities (Network metadata) that allow guest user access and correlate them with associated Guest User Profile metadata to detect excessive permissions (object, field, or Apex access). The rule flags communities where unauthenticated users may access or modify sensitive data.
Hypothesis
If a community allows guest access and the associated guest user profile has elevated permissions, then sensitive data or functionality may be exposed to unauthenticated users, leading to potential data breaches or unauthorized actions.
EXACT CONDITIONS TO FLAG
A. Object-Level Permissions
From:
<objectPermissions>
Flag if ANY of the following:
allowRead = true on standard objects:
Account
Contact
Lead
User
OR any custom object (__c)
OR
Any of these are true:
allowCreate = true
allowEdit = true
allowDelete = true
B. Field-Level Access (Sensitive Data Exposure)
From:
<fieldPermissions>
Flag if:
readable = true for sensitive fields like:
Contact.Email
Contact.Phone
Lead.Email
Any field matching patterns:
*Email*
*Phone*
*SSN*
*Password*
This is your PII exposure condition
C. Apex Class Access (Public Logic Exposure)
From:
<classAccesses>
Flag if:
<enabled>true</enabled>
Especially risky if:
Classes expose:
@AuraEnabled
REST endpoints
Parameters should be displayed as shown below:
Note: Regarding fields, the functionality should work as PII rule.
Value / Purpose
Detects real-world data exposure risks from misconfigured guest access
Prevents unauthenticated access to sensitive objects and fields
Ensures secure configuration of Experience Cloud communities
Reduces risk of public data leaks and compliance violations
Provides context-aware, high-confidence vulnerability detection
Acceptance Criteria
Name: Community Guest User Has Excessive Permissions Key: CommunityGuestUserAccess
Description: This rule identifies Salesforce Experience Cloud communities that allow guest access and where the associated Guest User Profile has elevated permissions such as object-level permissions (read, create, edit, delete), field-level access to sensitive data, or Apex class access. This may expose sensitive data to unauthenticated users.
Type: Vulnerability Severity: Critical Message: Guest user profile has elevated permissions in a community, which may expose sensitive data or allow unauthorized actions.
Tags: salesforce, security
CWE : 732
Remediation: 15 Minutes
Verification: We have verified the new Salesforce Metadata rule "CommunityGuestUserAccess" (Communities With Guest Access) and have validated via the following scenarios:
Rule correctly detects communities with guest access enabled.
Flags guest user profiles with elevated object-level permissions (read, create) on standard objects.
Flags guest user profiles with elevated object-level permissions (read, create) on custom objects.
Identifies sensitive/PII field-level access (Email, Phone, SSN patterns) on guest profiles.
Detects enabled Apex class access on guest profiles.
Configurable parameters (Sensitive Fields, Include Custom Objects) work as expected.
Rule severity correctly classified as Critical Vulnerability.
Above scenarios verified with Comparison branch as well, work as expected.
Re-run & Run manual verified regarding the new changes, both work as expected.
Notes:
To get the rule triggered correctly, make sure to add “Network” in codescan.cloud.packageTypes and “network” & “profile” in sonar.sfmeta.file.suffixes in project settings.
To give guest users access to the site's APIs, enable “Allow guest users to access public APIs” in Salesforce> Setup > all Sites > Workspaces > Administration > Preferences (or Builder > Settings > Public access)
To take away guest users access to the site's APIs, disable “Allow guest users to access public APIs” in Salesforce> Setup > all Sites > Workspaces > Administration > Preferences (Also verify Builder > Settings > Public access is disabled)
For custom sensitive/PII field-level access, configure “Filed Name” in the rule parameters. ( Field name and Field label can be different, get field name from sf org)
All verification use cases passed successfully, the rule is working as expected, and no issues were reported during verification.
Rule Enhancements
Enhanced logic in CodeScan Apex rule “Unused Formal Parameter” to address common false positives {Rule ID: sf:UnusedFormalParameter}
Description
Several customers had reported false positives associated with this rule. Upon analysis, we determined that at the Salesforce level, when parameters are consumed as SOQL bind variables inside a dynamically built query string, these parameters are generally used (and resolved from local scope at runtime). CodeScan was flagging them because its bind-detection only covers the IN :var form passed as a direct argument — not as strings built through the QueryFactory chain.
As such, we enhanced the rule logic to ensure that the rule (sf:UnusedFormalParameter) will not raise a violation when a method parameter is referenced as a SOQL bind variable within a string passed to dynamic SOQL execution.
The rule shall recognize bind variable usage for operators such as =, !=, >, <, >=, <=, and IN.
Existing support for IN :variable patterns shall remain unchanged.
A violation shall still be reported when a method parameter is genuinely unused.
We have verified that the rule sf:UnusedFormalParameter no longer raises false positives for formal parameters consumed as SOQL/SOSL bind variables (:var) in dynamic query patterns including fflib_QueryFactory and Database.query().
Fixes
Fixed grammatical error in CodeScan Project Summary Report
Description of issue: Misspelling in Project Report
Details: When users access the second page of a CodeScan Project report, there was a grammatical error in the error message: "There is no any issues in the project analysis yet."
We have updated error message to now display: “There are currently no issues in the project analysis.”
We have verified that the error messages have been properly updated to “There are currently no issues in the project analysis.” in the project reports. All reports are working as expected.
Verified in the new project’s report
Verified in the old project’s report
Verified in the scheduled cron job reports
Fixed issue with CSV Export where the "Status Marked By" Column was empty for Bulk Operations
Summary
The "Status Marked By" column in the CSV Issue Export is empty when issue statuses are changed via bulk operations (api/issues/bulk_change). The column works correctly when statuses are changed via single-issue operations (api/issues/do_transition).
Expected Result
The "Status Marked By" column should display the name of the user who performed the bulk status change for all affected issues.
We analyzed the "Status Marked By” population logic and found that bulk status change records were being skipped due to a startsWith() check. Updated the logic to correctly process bulk change entries and populate the user information. With this logic change, this issue has been fully remediated.
Scenarios Validated:
Bulk status change to CONFIRMED – "Status Marked By" column correctly populated with the user name
Bulk status change to EXCEPTION – Column populated as expected
Bulk status change to FALSE_POSITIVE – Column populated as expected
Bulk status change to ACCEPTED – Column populated as expected
Mixed bulk + single-issue transitions in same CSV export – Both reflect correct user names
Multiple bulk operations by different users – Each row shows the respective user who performed the action
Single-issue regression – No regression, column still works correctly for single transitions
Re-transition after bulk change – "Status Marked By" updates to the latest user
Issues with no status change – "Status Marked By" appropriately empty only for untouched issues - OPEN Status
Verified the same scenarios with Root-level admin, working as expected. Verified the same scenarios with PR, working as expected.
CodeScan Release Notes 26.0.14
Release Date: 28 June 2026
Summary
CodeScan 26.0.14 is comprised of the following components:
1 Fix
Component details are listed in their corresponding sections within this document.
Fixes
Resolved CI Jobs Analyzing Entire Codebase Instead of Delta Changes
Fixed an issue where CodeScan CI jobs could analyze the entire repository instead of only the files modified in the current pull request or commit.
Previously, delta analysis was not consistently applied in certain CI execution scenarios, causing CodeScan to process all files in the repository. This could result in longer analysis times, increased resource consumption, and findings unrelated to the current code changes.
Behavior
CI jobs now correctly analyze only the files included in the current delta (changed files).
Delta analysis is consistently applied across supported CI integrations.
Unmodified files are excluded from analysis when delta scanning is enabled.
Analysis execution time and resource utilization are reduced for incremental scans.
Results are focused on issues introduced or affected by the current changes.
Outcome
Improves CI pipeline performance and ensures analysis results remain relevant to the code changes being reviewed.
CodeScan Release Notes 26.0.13
Release Date: 21 June 2026
Summary
CodeScan 26.0.13 is comprised of the following 6 components:
0 New Features
1 Application Enhancements
1 New Rule
2 Rule Enhancements
0 Rule Deprecations
2 Fixes
Component details are listed in their corresponding sections within this document.
Application Enhancements
Enhanced CSV Export Reporting for Issues and Security Hotspots
Enhanced CSV export reporting for both Issues and Security Hotspots to provide additional information for ownership tracking, exception management, auditing, and compliance reporting.
Previously, CSV exports contained limited information, requiring users to manually retrieve assignment, severity, and exception details from within the CodeScan application.
New Export Fields
Issue and Security Hotspot CSV exports now include:
Severity
Assigned To
Assigned Date
Exception Expiry Date
Exception Reason
Exported data reflects the current state of issues and hotspots at the time of export.
Exception Reason Tracking Improvements
Issue exception reasons are now stored separately from standard issue comments, improving traceability and reporting accuracy.
Previously, exception reasons for Issues were stored using the same change type as standard comments, making it difficult to distinguish exception justifications from normal discussion history.
Reporting Improvements
The enhanced exports provide greater visibility into:
Severity classification
Ownership and assignment history
Exception lifecycle management
Expiring exceptions
Compliance and audit reporting activities
Issue CSV exports now clearly distinguish between:
Issue Comments
Exception Reasons
Fields are clearly labeled and consistently formatted within the generated CSV files.
The updated exports provide users with improved visibility into severity, ownership, exception status, and exception lifecycle details, making it easier to perform external analysis, compliance reviews, and governance activities.
Outcome
Improves auditability and compliance reporting.
Provides greater visibility into issue and hotspot ownership.
Simplifies exception tracking and lifecycle management.
Reduces the need to manually gather information from multiple areas of the platform.
Enhances offline analysis and reporting workflows.
New Rules
Connected App Missing Description
Added a new Salesforce Metadata rule to identify Connected Apps that do not have a defined description in metadata.
Connected Apps without descriptions can be difficult to govern because administrators may not have enough context about the app’s purpose, ownership, or access usage.
Rule Details
Rule key: ConnectedAppMissingDescription
Type: Code Smell
Default Severity: Major
Remediation effort: 2 minutes
Tags: salesforce
Behavior
The rule raises a violation when a Connected App metadata file does not contain a valid description.
Violations are raised when the description is:
Missing
Empty
Self-closing
Commented out
Whitespace-only
Defined only in an unrelated nested location
The rule does not raise a violation when a valid description is present, including descriptions with multiline text or special characters.
Message
Connected App does not have a description defined. Add a description for better governance and traceability.
Outcome
Improves governance and documentation of Salesforce Connected Apps.
Helps identify orphaned, unmanaged, or poorly documented integrations.
Supports security audits and compliance reviews.
Provides better visibility into app purpose and ownership.
Rule Enhancements
1. Improved Rule Engine Stability and Error Handling
Improved the stability and resilience of Apex rule execution by addressing multiple edge cases that could result in internal exceptions being exposed in analysis logs.
Previously, certain rule evaluation scenarios could generate internal exceptions during analysis, resulting in Java stack traces being written to logs. Although analysis often completed successfully, these errors could lead to incomplete rule evaluation and reduced confidence in results.
Edge cases addressed:
SOQL Injection Rule Stability
Improved handling of Apex data-flow analysis scenarios that could previously result in internal type-casting exceptions during rule evaluation.
LocaleInOldApiRule Stability
Improved handling of chained method invocations such as DateTime.now().format()to prevent internal rule execution errors while analyzing valid Apex code.
Defensive Null Handling Across Rule Execution
Enhanced null-safety handling for multiple Apex rules, including:
Unescaped Output
SOQL Injection
Avoid SOQL in Loops
Additional validation and defensive checks were introduced to ensure rule execution can safely handle unresolved AST and semantic-analysis paths without exposing internal exceptions.
Outcome
Improves overall rule engine stability.
Prevents internal implementation details from appearing in analysis logs.
Reduces the risk of incomplete rule evaluation.
Provides more reliable and professional analysis output.
Improves confidence in analysis results for Apex projects.
Enhanced Documentation for Sensitive PII Field Detection Rule
Updated the documentation and guidance for the Identify Potential Sensitive PII Fields rule (sf:SecurePIIFields) to provide clearer information about the types of data covered by the rule and how organizations can extend detection coverage.
Documentation Improvements
The updated rule description now clarifies that certain standard Salesforce objects may contain sensitive personal information, including:
Contact
Lead
User
Account
Person Account
Opportunity
Examples of potentially sensitive data include:
Names
Email addresses
Phone numbers
Physical addresses
Birth dates
Other personal identifiers
The documentation also highlights the importance of protecting this information in accordance with privacy and security regulations such as:
GDPR
CCPA
HIPAA
Configuration Guidance
Organizations can define additional sensitive field names through rule parameters, including:
SSN
Social_Security_Number
Credit_Card
Passport
and other organization-specific fields that may contain regulated personal information.
Outcome
Improves understanding of the rules' purpose and scope.
Provides clearer guidance for identifying and protecting sensitive data.
Helps organizations extend detection coverage to custom fields.
Supports privacy, security, and compliance initiatives through improved rule documentation.
Fixes
Resolved SAML Login Issue with Uppercase Organization Domains
Fixed an issue where users could be unable to log in when the organization's domain name contained uppercase letters.
Previously, the SAML login flow treated organization domains as case-sensitive. As a result, valid domains entered with uppercase or mixed-case characters could fail authentication, even though domain names should be handled case-insensitively.
Behavior
Organization domain matching is now handled case-insensitively during SAML login.
SAML connection creation now stores organization domain names consistently in lowercase.
Domains entered in lowercase, uppercase, or mixed case are handled correctly.
Leading and trailing spaces in domain input are handled safely.
Invalid domains continue to be rejected as expected.
Outcome
Improves SAML login reliability for organizations using mixed-case or uppercase domain entries.
Aligns organization domain handling with standard case-insensitive domain behavior.
Prevents valid users from being blocked due to domain capitalization differences.
Resolved Salesforce Integration Error When Using Previous Test Run Results
Fixed an issue that could prevent Salesforce integrations from running successfully when configured to use unit test results from a previous execution.
Previously, analyses configured with the Use previous run option could fail while attempting to retrieve historical test execution data.
Behavior
Corrected the retrieval of previous unit test execution results.
Improved handling of Salesforce test coverage queries and historical test result lookups.
Analysis now successfully reuses previously executed unit test results when available.
Organizations without prior test execution history are handled gracefully.
Outcome
Improves the reliability of Salesforce integrations using previously executed unit tests.
Prevents failures caused by test result retrieval errors.
Reduces unnecessary test execution by allowing the successful reuse of historical test results.
Provides more resilient handling of organizations with limited or no prior test execution history.
CodeScan Release Notes 26.0.12
Release Date: 7 June 2026
Summary
CodeScan 26.0.12 is comprised of the following 8 components:
3 Application Enhancements
1 New Rule
1 Rule Enhancement
3 Fixes
Component details are listed in their corresponding sections within this document.
Application Enhancements
Instance-Level Severity Masking
Added support for instance-level severity masking, allowing CodeScan Administrators to centrally customize how severity labels are displayed across the platform while preserving underlying severity values, analysis behavior, and reporting logic.
Previously, severity labels were displayed using the default values throughout CodeScan and could not be customized at the instance level. This enhancement introduces centralized severity masking that is consistently applied across the Web UI, reports, exports, APIs, and IDE plugins.
Behavior
Administrators can configure severity label mappings through the Admin UI.
Severity masking settings are stored and managed at the instance level.
Severity mappings are exposed through secure APIs and applied consistently across the platform.
Custom severity labels are displayed throughout:
Web UI
Reports
CSV exports
SARIF exports
IDE plugins
Default severity labels are automatically used when no severity masking configuration exists.
Changes are applied immediately without requiring a refresh.
Supported Default Severity Labels
Blocker
Critical
Major
Minor
Info
Validation
Validation is enforced at both API and UI levels.
Invalid severity mappings are rejected with clear error messages.
Only administrators can modify severity masking settings.
Unauthorized users are restricted from making configuration changes.
Functional Integrity
Severity masking affects display labels only. The following behaviors remain unchanged:
Underlying severity values
Issue counts and metrics
Quality Gate evaluations
Severity-based sorting
Severity-based filtering
Analysis processing
Reporting calculations
Export generation
SARIF standards compliance
IDE plugin workflows
Downstream integrations
Outcome
Provides consistent severity representation across the entire CodeScan platform.
Enables centralized governance of severity terminology.
Reduces inconsistencies between Web UI, reports, exports, and IDE plugins.
Preserves existing functionality and compatibility with integrations.
Exception Expiry Notifications
Added subscription-based exception expiry notifications for Issues and Security Hotspots, enabling users to receive automated reminders before approved exceptions reach their expiry date.
Subscription Management
Users can now manage exception expiry notification preferences through:
Profile → My Account → Notifications
Notification options are available in:
Overall Notifications
Project Notifications
Project-level notification settings
Users can enable or disable exception expiry notifications based on their preferences.
Reminder Notifications
Subscribed users receive automated email reminders for Issues and Security Hotspots with approved exceptions.
Notifications are sent:
One week before expiry
One business day before expiry
Business-day scheduling is automatically applied.
Notification Controls
Notifications respect:
User notification preferences
Project notification settings
User permission settings
Notifications are not sent for:
Archived organizations
Deleted projects
Unsubscribed users
Outcome
Helps teams proactively review exceptions before they expire.
Reduces the risk of unnoticed expired exceptions.
Improves compliance and governance processes.
Provides users direct control over exception-related notifications.
Rules Evaluation Export Report
Added a new Rules Evaluation Export Report that provides visibility into all rules evaluated during a scan, including scans where no issues are detected.
Behavior
A new export option, CSV Rules Evaluation Report, is available from the More menu.
Users can select:
Project
Branch
and export a report containing all rules evaluated during the selected scan.
Report Contents
The report includes:
rule_key
rule_name
rule_language
rule_category
rule_severity
issues_found
Rules are included regardless of whether violations were detected.
Outcome
Improves auditability and compliance reporting.
Provides visibility into scan coverage.
Allows users to validate rule execution even when no issues are found.