Rob Behnke
April 17th, 2024
The software development lifecycle (SDLC) maps the various stages of software development from defining the requirements for the software through its retirement at end of life.
While definitions of the stages of the SDLC vary, they largely map to the following stages:
Requirements
Design
Development
Testing
Deployment
Operation/Maintenance
One of the benefits of the SDLC is that it tends to be globally applicable. Whether writing low-level C++ firmware code or a JavaScript web application, the stages are generally the same with only small modifications.
Web3 — with its use of blockchain technology — changes things. This article explores some of the main differences that the blockchain’s unique infrastructure introduces into the SDLC.
The requirements and design phases of the SDLC address a few different aspects of the software. The first is that the software needs to perform certain tasks. The others are that it also needs to do so within a particular deployment environment and achieve its goals securely. Software requirements and design are intended to outline these needs and then plan out a way of fulfilling them.
In Web3, software requirements and design have the same set of core goals. However, the differences in infrastructure and environment introduce significant differences from Web2.
Firmware and the various types of software are very different from one another. However, they are all designed to run on a single, semi-trusted computer. In some cases, an application may be designed to run within some form of sandboxed environment, such as a virtual machine or browser.
Web3 applications operate in a much more complex environment. While they still run on a traditional computer, there are several layers of abstraction between a smart contract and the traditional application layer, including the blockchain software itself and its virtual machine. The introduction of Layer-2s, such as rollups, only adds to this abstraction.
The end result is that smart contract requirements and designs need to account for all of these differences to produce a secure, functional program. Without an understanding of how the blockchain works, the impacts of gas in Ethereum, and other factors, it’s easy to create smart contracts that are woefully insecure or completely non-functional.
The blockchain space is even more fragmented than that of traditional computers and operating systems. While there are 2-3 main flavors of OS — depending on whether macOS is considered a Unix/Linux variant or stands alone — there are dozens of major blockchain platforms.
Several Web3 projects are designed to operate on multiple different blockchains, which requires smart contract code to be deployed, operational, and secure on each. With subtle or major differences between each platform, creating a multi-chain project is much more complex than compiling C++ code for each of the OS variants.
Smart contract developers are writing code that will be deployed on the blockchain. The unique nature of blockchain environments introduces additional requirements and raises the stakes for smart contract security.
Web2 projects have goals regarding application performance and efficiency. For example, page load speed is a critical factor for conversions in web content. However, these limitations and rules largely affect the performance or profitability of an application rather than its functionality.
In Web3 contexts, some of the same factors that are optimizations in Web2 are hard limits. For example, Ethereum’s use of gas limits means that only a certain amount of functionality can be crammed into a single transaction, and exceeding this limit causes the whole transaction to fail rather than simply stopping when it runs out of gas. Software development for Web3 needs to take these considerations into account for code to be functional at all, and the fact that every instruction has a set price makes gas optimization essential.
In theory, security by obscurity is a bad idea. In practice, many Web2 programs take advantage of it, encoding and obfuscating code to make it more difficult to reverse engineer. By doing so, they slow and potentially prevent detection and exploitation of vulnerabilities in their code.
In Web3, open source, verifiable code is the default for most reputable projects. While this has its benefits, it also provides attackers with the ability to analyze source code for vulnerabilities.
As a result, smart contract developers need to take extra care to prevent vulnerable code from being deployed.
Vulnerability detection and remediation is essential to shipping good code. However, despite the fact that the field of software development is decades old, numerous security testing tools are available, and the top vulnerabilities are well-documented, vulnerabilities in production software still rise each year.
Smart contract programming is a much younger field, and, as mentioned above, the development landscape is much more fragmented. As a result, many blockchain solutions lack the same tools and build-up of institutional security knowledge, increasing the probability of vulnerabilities reaching deployment.
Most programs spend the vast majority of their time in the maintenance stage of the SDLC, performing their role until end-of-life. With smart contracts, blockchain immutability has a significant impact on the security risks that these programs face.
Web2 systems are built around upgradeability. Even firmware is designed to undergo periodic upgrades to add features or close security gaps. This ability to fix errors in production is a major reason why growing numbers of vulnerabilities haven’t completely broken Web2 systems.
In Web3, however, smart contracts are deployed to an immutable blockchain. This means that patches and updates can’t easily be pushed out when something goes wrong.
As a result, smart contracts need to be explicitly designed to be upgradeable. While this is possible, it also can introduce other security risks if not managed properly, as demonstrated by the recent Munchables hack.
Blockchain immutability and visibility also has impacts on users’ interactions with smart contracts. When a user performs a transaction, it is generally publicly visible in mempools. This creates the potential for frontrunning attacks, a security risk that developers need to manage.
Once executed and written to the digital ledger, transactions are also immutable. This means that exploit transactions are permanent and attacks can’t be rolled back, restoring smart contracts to their previous, pre-hack state. This raises the stakes for smart contract security testing since the effects of attacks targeting any vulnerabilities that reach production are permanent.
Traditional software development is working to adopt DevSecOps or Shift Left security, where security is integrated earlier in the SDLC. By doing so, it can reduce the probability that those vulnerabilities reach production where they could be exploited and are more expensive to fix.
However, the ability to perform updates and roll back many hacks decrease the stakes and the incentive to implement DevSecOps.
Web3 is different, and the unique nature of the blockchain makes the stakes of poor security much harder. Implementing DevSecOps and ensuring that all code is audited before release is essential for security. For help in securing your Web3 project and navigating the complex challenge of the Web3 SDLC, get in touch with Halborn.