Ethereum: Adapting security tooling to blockchain-built software

Blockchain native software is in its infancy but the technology races forward to meet more and more use cases. The community has not seemed to have taken software security principals seriously as we can see from the recent scan of Ethereum smart contracts that identified 34,200 vulnerable contracts.

For added perspective, a smart contract is a piece of software which contains business logic for moving around balances, or changing the key-value-pairs stored on the blockchain.

Poor choices in architectural design of the Ethereum "virtual machine" and smart contract programing languages make even security conscious developers susceptible to simple mistakes with severe consequences. With huge amounts of money being invested in blockchain software startups, more effort must be made by the community to improve the platforms the software is built on.

Considering new threats

Traditional tooling for secure software development have not yet adapted to blockchain-centric software. Highly distributed and trustless systems introduce entirely new threats and require new ways of reasoning about software flaws.

New research papers and accompanying tools are released every week but the community has not yet reached consensus on best practices for developers to work from. Once a vulnerability is found, the unalterable nature of blockchain technology can make patching existing contracts difficult or effectively impossible. Given this inflexibility, we must adopt a more forward-looking approach to security and develop tools and best practices for eliminating bugs before they make their way into the blockchain.

The following software security activities are likely to make their way into every smart contract development cycle:

Secure code frameworks

Developers need audited and proven frameworks for creating secure code from common patterns. This may include safe math operations, authentication and authorization, or monetary transaction handling.

Static code analysis and code linting

Tools today can identify common code smells and eliminate low hanging fruit bugs in Solidity code. In the future these tools must be framework aware and contain more security related rule sets.

Dynamic code analysis tools

The Maian tool discussed in the National University of Singapore paper is an example of hybrid static analysis with concrete execution which discovers complex flaws which would be missed by traditional static tools that lack symbolic execution. Many new smart contract analysis tools do not generally need source code and can be used to scan the entire public blockchain for potentially vulnerable contracts.

Threat modeling

Non-trivial applications deployed on blockchain technology needs a process to systematically identify all components of the system, potential threat actors, and controls provided by the platform. Conclusions can then be drawn about the security of the system as a whole and where additional security measures can be added to compensate for identified threats.

Secure governance and policy creation

Traditionally blockchain contracts were inalterable and trust from users was put in the veracity of contract code. Today, no contract is safe from hacks and bugs and so contract vendors need to create policies around consumer and asset protection. Smart contracts developers must consider polices for patching live contracts and methods for handling incident response.