Release Notes 26.1.1 Eagle 8.0

Release Date: 17 July 2026

Summary

CodeScan Self-hosted 26.1.1 is comprised of the following 6 components:

• 0 New Features
• 0 Application Enhancement
• 0 New Rules
• 3 Rule Enhancements
• 0 Rule Deprecations
• 3 Fixes

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

Rule Enhancements

1. Improved Rule Stability and Error Handling

Improved the stability and resilience of Apex rules 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 is 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.

• LocaleInOldApi Rule 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

1. Improves overall rule engine stability.
2. Prevents internal implementation details from appearing in analysis logs.
3. Reduces the risk of incomplete rule evaluation.
4. Provides more reliable and professional analysis output.
5. Improves confidence in analysis results for Apex projects.

2. 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.

3. Enhanced Avoid Calling SOQL and DML Inside Loops Rule

Enhanced the sf:AvoidSoqlInLoops rule to optionally detect Salesforce platform methods that consume SOQL queries internally when executed within loops.

New Parameter

Parameter	Default	Description
checkInternalSoql	false	Checks for methods with internal SOQL consumption used within loops.

Behavior

When enabled, the rule identifies supported platform methods that may consume hidden SOQL queries inside loops, for example:

• Messaging APIs
• UserInfo APIs
• FeatureManagement APIs
• Approval APIs
• Flow invocation APIs
• ConnectApi operations
• Visualforce content APIs

Outcome

• Improves detection of governor limit risks.
• Identifies hidden SOQL consumption.
• Helps developers avoid query-limit violations.
• Preserves existing behavior unless explicitly enabled.

Fixes

1. 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.
• Exclusion of Apex test class method calls from nested execution path analysis.
• 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.
• Prevents Apex test classes from influencing production rule evaluation.
• Provides developers with more reliable and actionable rule findings.
• Improves confidence in SOQL and DML loop detection for complex Apex applications.

1. 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.

1. Improved Unused Formal Parameter Detection for Dynamic SOQL Queries

Enhanced the Unused Formal Parameter rule (sf:UnusedFormalParameter) to improve detection of method parameters used as bind variables in dynamically constructed SOQL queries.

Previously, the rule could incorrectly report unused parameter violations when parameters were referenced as bind variables within dynamic query strings, such as queries built using the fflib QueryFactory pattern. Although these parameters were resolved and used by Salesforce at runtime, they were not recognized by the rule, resulting in false-positive findings.

Behavior

The rule now recognizes method parameters used as SOQL bind variables within dynamic query execution patterns, including:

• Database.query()
• fflib_QueryFactory
• Dynamically constructed SOQL query strings

Support has also been expanded to recognize bind variables used with common SOQL operators, including:

• =
• !=
• >
• <
• >=
• <=
• IN

Existing detection for direct IN :variable usage remains unchanged.

The rule continues to report violations for method parameters that are genuinely unused.

Outcome

• Reduces false positives for applications using dynamic SOQL construction patterns.
• Improves compatibility with the Salesforce Enterprise Patterns (fflib) framework.
• Provides more accurate detection of genuinely unused method parameters.
• Increases confidence in rule results for projects using dynamic query generation.