Byte Sized Security: Unraveling the Toolkit of a Digital Security Sherlock Holmes

In the Byte Sized Security series, the Highland Security team takes a complex security topic and simplifies it to be bite-sized. If you want more detailed information or a specific approach for your project, contact us and lets talk security!

A Diverse Spectrum of Testing Tools

Constructing a robust software security testing framework entails a multifaceted approach, encompassing various testing methodologies and tooling. In part 1 of this series we looked at the different types of vulnerability classes suited for automated security tools. In this part we will explore delve into the different types of testing tools and give examples on how they fit into a comprehensive web3 software security strategy:

E2E/Unit Tests: Safeguarding at the Micro and Macro Levels

End-to-end (E2E) and unit tests constitute the bedrock of any web3 software testing regimen. Prior to launch every web3 product should have a comprehensive test suite for each functionally component and user flow. By augmenting these tests with security checks, like for example ensuring whitelist or blacklist functionality works as expected developers can start to ensure that both functional and security features of the codebase are working as expected. While important, these types of tests alone do not provide adequate security coverage because for the most part they are evaluating if a feature or function is working properly under expected conditions. Some common tooling for these types are Foundry/Forge and Mocha framework. 

Harnessing the Power of Static Analysis

Static analysis scrutinizes the source code sans execution. These are  formidable tools that can uncover potential vulnerabilities by identifying vulnerable code patterns. Running these checks and maintaining an up to date inventory of detectors is a great way to automate the early detection of security issues that could escalate if left unresolved. While these tools are great at detecting code patterns, usually some manual inspection and review is still necessary to confirm if it's a bug or a false positive. It’s also important to recognize these tools are usually only as good as the rulesets/detectors that are used. Some common tooling for static analysis of Solidity code are slither, semgrep, and solgrep. 

Fuzzing and Symbolic Execution: Navigating the Uncharted Territories

In part 1 we mentioned invariants and why they are important. To recap an invariant is a condition in your smart contract system that always must hold true. For example In ERC20 systems a common invariant is the sum of all user balances and reserves must always equal the total supply. Constructing functional and system level invariants empowers security tools to verify the accuracy of particular behaviors within the software using fuzzing and symbolic execution. Fuzzing entails introducing unexpected inputs to an application to uncover vulnerabilities. Symbolic execution, on the other hand, analyzes program paths to detect flaws in code logic that could compromise security. These tools replicate the system’s state after executing a test case in order to identify unexpected states and report the violating condition. If used properly, these two tools are extremely useful to verify critical conditions are still true after each code change. Some common tools that can be used for fuzzing/symbolic execution are Echidna, MthX (a paid service), Manticore, and fuzzland’s ityfuzz.

Coming up next!

Using these tools a protocol team can proactively add basic security capabilities to their operational testing capabilities. As with any type of tool the value you get from these tools are intrinsically linked to the input and maintenance over time. In the next post of this series we will explain a practical implementation of the static analysis tool Slither into your CI/CD pipeline using Github actions. If you are interested on how these types of tools can be used on your web3 products, contact us today for a free consultation!