RWA/RBAC - Securitize

1. Introduction

Securitize engaged Halborn to conduct a security assessment on their Solana Validator program beginning on February 10th, 2025 and ending on March 3rd, 2025. The security assessment was scoped to the smart contracts provided in the GitHub repository rwa-rbac, commit hashes, and further details can be found in the Scope section of this report.

The Securitize team is releasing rwa-rbac, a program that acts as a facade for all RWA-related programs, enforcing role-based permissions before allowing access to critical functions via CPI (Cross-Program Invocation). The Securitize team is also releasing rwa-imr , a program that extends investor data without bloating the IdentityAccount in the Identity Registry. It relies on the Identity Registry for authority validation, as all instructions execute a CPI into the IRP.

2. Assessment Summary

Halborn was provided 16 days for the engagement and assigned one full-time security engineer to review the security of the Solana Programs in scope. The engineer is a blockchain and smart contract security expert with advanced smart contract hacking skills, and deep knowledge of multiple blockchain protocols.

The purpose of the assessment is to:

• Identify potential security issues within the codebase.

• Validate that all the requirements presented by the client are strictly implemented on code

• Verify that all the necessary functions are implemented to be accessed through RBAC/CPI

• Check that the role-based access control implemented in the RBAC program follows a secure methodology.

In summary, Halborn identified some improvements to reduce the likelihood and impact of some risks, which were completely addressed by the Securitize team. The main ones were the following:

• Implement the creation of an AssetController through CPI when creating an AsssetAccessController.

• Implement RBAC/CPI enforcement for the CreatePolicyEngine and CreateTrackerAccount entry points in the PolicyEngine program.

• Prevent the AssetAccessController's admin to have the ability to invoke all RBAC/CPI entry point.

3. Test Approach and Methodology

Halborn performed a combination of manual review and security testing based on scripts to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of the code and can quickly identify items that do not follow the security best practices. The following phases and associated tools were used during the assessment:

• Research into architecture and purpose.

• Differences analysis using GitLens to have a proper view of the differences between the mentioned commits

• Graphing out functionality and programs logic/connectivity/functions along with state changes

4. Automated Testing

Halborn used automated security scanners to assist with the detection of well-known security issues and vulnerabilities. Among the tools used was cargo-audit, a security scanner for vulnerabilities reported to the RustSec Advisory Database. All vulnerabilities published in https://crates.io are stored in a repository named The RustSec Advisory Database. cargo audit is a human-readable version of the advisory database which performs a scanning on Cargo.lock. Security Detections are only in scope. All vulnerabilities shown here were already disclosed in the above report. However, to better assist the developers maintaining this code, the reviewers are including the output with the dependencies tree, and this is included in the cargo audit output to better know the dependencies affected by unmaintained and vulnerable crates.

Results