a16z: How to build a development process that improves smart contract security

Web3 projects should consider adding processes for security at all stages of the development lifecycle.

Many of the hacks that have happened to Web3 projects could have been prevented by strengthening the security of smart contracts.

Often, attackers find and exploit flaws throughout the software development chain—from design to deployment and maintenance and release of new code. If there is a standard smart contract development and risk response process, we believe that security incidents will be reduced accordingly.

The purpose of this post is to outline the core security factors that Web3 builders, developers, and security teams must consider when designing, developing, and maintaining smart contract systems. The following framework discusses eight core security factors that should be implemented throughout the software development lifecycle—from threat modeling to emergency response preparedness.

Before understanding smart contract security protection, it is necessary to understand the development stage of software. Software development can be divided into the following five phases:

Design : The developer describes the required functionality and operation of the system, including important benchmarks and fixed properties.

Development : Developers write the code for the system.

Testing and review : Developers run all modules in a test environment to assess code accuracy and stability.

Deployment : The developer puts the system into the live environment.

Maintenance : Developers evaluate and modify the system to ensure it performs as intended.

With this foundation of a basic development cycle in place, we can now drill down to the considerations that affect smart contract security at each step. The diagram below maps the factors to be considered to the relevant development phases. It should be noted that some steps in the link have multiple security considerations:

As shown above, the software development life cycle does not always follow a linear path. In practice, there may be overlap or extension to other phases. Some steps may need to be repeated for each release. Some tasks—such as testing and security reviews—may need to be performed from beginning to end.

The software lifecycle and corresponding security considerations described above provide useful foundational information for promoting the security of smart contracts, but we will examine them in more detail below to make it possible to understand, apply, and share these practices Simple, and concretely analyze the key questions: What, Why and How.

Smart Contract Security Considerations in the Design Phase Consider Threat Modeling and Security Design

What: It is important to implement concrete plans for identifying and prioritizing potential threats to the system from the very beginning of the development life cycle - smart contract developers should identify all security controls to be All threat testing, auditing and monitoring of the inspection. All security assumptions, including the expected sophistication and means of attack, should be clearly defined and articulated during the design phase.

Why: While developers tend to focus only on the intended use of a smart contract or protocol, this singleness of focus can leave them with blind spots that can be exploited by attackers.

How: Follow known threat modeling practices. If the development team does not have in-house security expertise, it should work with security consultants early in the design phase. Adopt an "attacker" mentality when designing systems and assume that any individual, hardware or service can be attacked.

Security considerations during the development phase Consider management and access control

What: Implement access control, limit the permissions of privileged accounts and smart contracts invoke special functions that perform administrative tasks (such as upgrading contracts and setting special parameters). Follow the "principle of least privilege": each participant should only have the minimum access privileges needed.

Why: Maintaining the protocol through the upgrade and governance process allows developers to improve the protocol by adding new features, patching security issues, and optimizing for changing conditions. This could constitute a serious security breach if the ability to upgrade is not properly controlled.

How: Build a multi-signature wallet or DAO contract that will make changes to the protocol transparent and should go through a thorough review process as well as timelocks (deliberately delayed enactment with cancelability) to ensure they can be verified correct and happen Rollback on governance attack. Make sure privileged keys are securely stored and accessible in a self-hosted wallet or secure escrow service.

Consider integrating reusable, tried and true templates

What: Leverage existing smart contract standards as much as possible (such as OpenZeppelin Contracts) and assess possible security issues in the integrations you may need with existing protocols.

Why: Using existing battle-tested, community-vetted standards can go a long way in reducing security risks. Assessing the risks of protocol integration helps you perform security checks to prevent attacks against external components, such as oracle manipulation.

How: Import trusted contract libraries and interfaces that have undergone security audits. After all, the focus of Crypto and Web3 is open source, reuse, and composability. Be sure to document your contract dependencies and their versions in your codebase, and minimize the resource footprint of your code; e.g. import specific submodules of large projects instead of everything; know your exposure so you can monitor attack; use the official interface to call external protocols, and make sure to consider potential integration risks; monitor updates and security information disclosure of your reused contracts.

Security considerations for testing and review phases Consider testing and project documentation

What: Create clear, comprehensive code documentation and set up quick, comprehensive, easy-to-run test suites. Where possible, conduct more in-depth experiments on a testnet or in a test environment set up with a mainnet simulation.

Why: Writing assumptions for expected behavior not only helps ensure risks in the threat model are addressed, but also helps users and external auditors understand the intent of the development team. Creating test suites for code can help prove or disprove assumptions and encourage deeper thinking about threat models. This test suite should include mechanical design tests that check the project’s token economics under extreme market scenarios, as well as unit and integration tests.

How: Test with known testing frameworks and security check applications - such as Hardhat, Mythril, Slither, Truffle, etc.; provide different testing techniques, such as fuzzing, property-checking, and even formal verification (formal verification); thoroughly document your code, using NatSpec annotations to specify expected side effects, parameters, and return values. Generate live documentation using documentation generation tools and high-level design notes.

Consider internal reviews and security audits

What: Take the time to find bugs through internal and external code audits.

Why: Shifting from feature development to security issues gives developers time to discover potential security issues. External audits can be particularly useful in this regard, as they can bring outside perspective and expertise that the development team does not have.

How: At an appropriate point in project development, schedule a feature freeze to allow time for an internal review followed by an external audit. These actions should be taken before live deployments and upgrades, check out the guides from ConsenSys, Nascent, OpenZeppelin, and Trail of Bits that provide developers with a checklist of things to consider -- including timing -- for anyone preparing to audit . Also make sure to review deployment transactions to ensure they use audited code versions and have appropriate parameters, especially when upgrading software.

Security considerations during deployment and maintenance phases Consider motivating white hat community participation

What: Create a program that encourages community participation in security improvements to open source codebases. One approach is to establish bug bounties. Another approach is to encourage the community to develop protocols to monitor and detect bots.

Why: Development teams can benefit from broader knowledge and experience (again, open source helps Crypto as well). Notably, such programs can help spark developer enthusiasm for a project, essentially turning the community and white hat hackers into evangelists. They can also help turn would-be attackers into defenders by giving hackers a way to become defenders.

How: Use a bug bounty platform (such as Code4rena, HackenProof, Immunefi, or Secureum) to provide severity-based rewards to the bounty system to incentivize skilled hackers to disclose vulnerabilities. (Disclosure: Some of the co-authors of this paper work for Forta, a network that provides a token incentive structure for creating decentralized high-quality security monitoring bots.) Development teams can encourage their protocol communities to leverage traditional and Web3-native approaches To incentivize the search for bugs and allow participants to earn potential rewards for enhanced security, creating a win-win for all.

Consider real-time monitoring

What: Implement systems that monitor smart contracts and key operational components such as oracles and cross-chain bridges, and report suspicious activity to the development team and community based on known threat models.

Why: Early detection of issues enables teams to respond quickly to vulnerabilities and bugs, potentially preventing or mitigating damage. This seems like an easy idea to think of, but it might be overlooked in planning.

How: Use a monitoring platform or a distributed node to run a robot that monitors smart contract events in real time. Build dashboards and alert notifications for development teams and the wider community as needed.

Consider Incident Response Processes

What: Leverage tools and processes that can respond immediately to any security issue as it arises.

Why: Even with the best pre-deployment protections in place, there can still be temporary issues with smart contracts and key components such as oracles and cross-chain bridges. Having dedicated people, clear processes, and automation in place ensures that incidents can be investigated quickly and resolved as quickly as possible.

How: Prepare for the worst by planning how to respond to an incident or emergency and automating that response to the greatest extent possible. This includes assigning investigation and response responsibilities to competent individuals who can publicly contact those related to security concerns through distributed security mailing lists, instructions in code repositories, or smart contract registries. Based on the agreement's threat model, develop a process that may include scenario exercises and expected response times for urgent action. Consider integrating automation into incident response: For example, a tool could receive events from a Forta robot and act on them.

Security considerations should be an integral part of successful development, not just an afterthought.

While the above framework provides some quick guidelines for teams building Web3 protocols and applications to improve security throughout the development process, a brief overview is not enough to provide an exhaustive discussion of all aspects of smart contract security. Teams that lack in-house security expertise should contact qualified Web3 security experts who can help teams apply the general guidance above to their specific situation. But most importantly, remember that security is much more than simply ticking a checklist to manage complex issues, it is always a never-ending, ongoing set of practices. We're still in the beginning stages of establishing these practices, so now is the time to collaboratively create and share security practices for all developers.