In recent years, many organizations have adopted more modern development practices, including Agile, Scrum, and DevOps. The goal of these new processes is to improve the pace and efficiency of development by streamlining the development process and using automation whenever possible.
One of the main shortcomings of most DevOps programs is that they overlook security, focusing on getting software released as quickly as possible. As a result, tens of thousands of vulnerabilities reach production each year, putting customers at risk. Additionally, fixing vulnerabilities in production is costlier than in the development and steals resources away from developing new software.
With the rise of smart contracts and decentralized finance (DeFi), software development is increasingly moving to the blockchain. However, traditional development practices – with security treated as an afterthought – do not work for blockchain environments. Blockchain developers must adopt DevSecOps practices and tools to ensure the usability and security of their projects.
Blockchain Development is Different From Traditional Development
Vulnerability management and secure coding are important for both traditional and blockchain development. In both cases, vulnerable code exploited by an attacker can have a dramatic impact on a company and its customers.
However, the environments where traditional software and smart contracts operate are very different. Traditional software is designed to run on a computer, while smart contracts run on top of the blockchain. The differences between these two ecosystems create significant challenges for smart contract developers and amplify the potential impacts of attacks against software hosted on the blockchain.
The Blockchain Ecosystem is Fragmented
For traditional software development, there are only a few environments that software developers work in. Computer operating systems are largely broken up into Windows and *nix (Linux, Mac, etc.). While differences exist between Windows versions or Linux flavors, the overall consolidation of the ecosystem makes it easier for developers to understand how a platform works and how to write secure, effective code for it.
The blockchain ecosystem is much more fragmented. Smart contract platforms are still in their early stages of development with new contenders trying to unseat more established platforms, such as Ethereum. As a result, there are many more smart contract platforms than there are types of OSes.
Most smart contract platforms use their own virtual machines (VMs) to run smart contracts. Some of these are developed in-house, while others use existing systems (such as the Java Virtual Machine). Each VM has its own quirks and idiosyncrasies, making it more difficult for developers to create functional and secure code that runs in different smart contract environments.
Blockchain is Relatively New
Modern digital computers have been around since the 1940s, and the concept originated over a century before. Since then, computer usage and the development of computer programs have grown rapidly and dramatically. Despite this, vulnerabilities are still common, and the same programming errors appear again and again.
Compared to computers, smart contract platforms are relative newborns. Ethereum, the oldest smart contract platform, launched in July 2016, and its competitors are even younger. This means that developers lack the same level of experience with smart contract programming languages and virtual machines that they have with more established languages and environments. Smart contract programming is riskier because many developers lack the experience to do it properly, and the environments themselves lack the maturity and level of security testing of traditional computers.
Everything is “Open Source”
Exploiting vulnerable software is always easier with access to the source code. With the ability to read the code, a potential attacker can use static code analysis tools and more easily understand the intended function and flow of code and where vulnerabilities may exist. For this and other reasons, many organizations do not publish their source code.
On the blockchain, all smart contract code is essentially open-source. Many blockchain projects publish their source code, and decompilers exist for those that do not. While decompiled code is not as readable as the original, it is good enough for most attackers’ purposes.
The open-source ecosystem of the blockchain makes it far easier for potential attackers. The ability to read the source code and understand the developers’ logic (and the potential flaws it contains) makes smart contract exploitation easier in general than with traditional, closed source code.
Software Updates Aren’t Easy
Traditional software development processes are heavily dependent on the ability to update the software when needed. The many vulnerabilities that reach production can be easily addressed by sending out an update with better, more secure code. This upgradeability is the foundation of agile development as well because it allows the software to be built and deployed in segments.
On the blockchain, software updates, while possible, are not as easy to perform. The blockchain is designed to maintain an immutable digital ledger, meaning that any transactions performed on the blockchain cannot be changed after they have been added into a block that is validated and accepted by the network.
Smart contract code is deployed as a blockchain transaction and stored on the immutable digital ledger. If vulnerable code is pushed to the blockchain, it cannot be easily overwritten with better, more secure code as is possible for traditional software. While smart contracts can (and should) be written to allow updates, this must be an intentional feature of the design and implementation and is not supported by default.
Exploitation is Easy
It’s a cliche that a criminal needs means, motive, and opportunity. For smart contract exploitation, the means is a vulnerability and the motive is the fact that many smart contracts (especially in the DeFi space) store massive amounts of value. Smart contract hackers have plenty of motivation and weak development practices provide the means needed to exploit them.
The design of the blockchain also provides ample opportunity for an attacker to exploit smart contracts. Most major blockchains are designed to be open, permissionless platforms, meaning that anyone can create an account and perform transactions on them. While a particular smart contract may require privileged access to certain functions or data, most smart contracts are designed to have functions that are publicly accessible.
This means that smart contract attackers can easily gain the access needed to exploit a vulnerable smart contract. The blockchain makes it easy to create an account and send transactions to vulnerable software running on top of it. Additionally, the pseudo-anonymity of the blockchain also makes smart contract exploitation relatively low-risk because it is extremely difficult to attribute a particular account and the attacks performed by it to its real owner.
Attacks Are Not Easily Reversible
In traditional IT, many of the biggest types of cyberattacks are reversible given the right resources. An attack by ransomware or wiper malware can be fixed by restoring any encrypted or deleted data from backups. Financial fraud can sometimes be reversed if a financial institution is contacted in time. An infected computer can always be restored to operation by reinstalling its operating system.
The blockchain, on the other hand, is designed to implement an immutable digital ledger. Once a transaction is performed on the blockchain, it is relatively permanent. This means that, except in very rare cases (such as the Ethereum DAO hack), a successful attack is not reversible.
This fact dramatically raises the stakes of smart contract security. Without the ability to undo a successful hack, smart contract developers need to ensure that the hack cannot happen in the first place, which requires strong code security.
Blockchain Development Requires Strong DevSecOps Practices
Traditional development practices often focus on time to release instead of security. This is also true of many blockchain projects as developers try to release new projects as quickly as possible to beat the competition or take advantage of the hype.
Integration of security into the development process or “DevSecOps” is vital for traditional development. The massive and growing number of vulnerabilities discovered in production software each year is unsustainable and places customers at risk.
However, strong DevSecOps is arguably even more important for blockchain projects due to the unique nature of the blockchain ecosystem. Many smart contract-based projects are high-profile and valuable, making them tempting targets for attackers. At the same time, it is more difficult to write secure code and to fix any issues that are discovered after a project is released to the blockchain. Additionally, smart contract hackers have significant advantages because they can often read a project’s source code, they can easily gain the access needed to perform their attacks, and a successful attack is not easily reversed.
Managing the threat of insecure code on the blockchain requires developers to embrace the DevSecOps movement and update their development pipelines to better integrate security. Tools exist for detecting vulnerabilities in smart contract code, and many of these can be integrated into automated development pipelines. By taking advantage of these solutions and auditing all code before launching it on the blockchain, smart contract developers can minimize the threat that vulnerable code poses to them and their users.
This article is the first in a series on improving smart contract security. Keep an eye out for future articles on smart contract security auditing tools, security best practices, and other key aspects of smart contract security.
For over 30 years, Marin Ivezic has been protecting critical infrastructure and financial services against cyber, financial crime and regulatory risks posed by complex and emerging technologies.
He held multiple interim CISO and technology leadership roles in Global 2000 companies.