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

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

Many of the hacks that happen to Web3 projects can be avoided by hardening the security of smart contracts.

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

The purpose of this article 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 the security protection of smart contracts, it is necessary to understand the development stage of the software. Software development can be divided into the following five stages:

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

Development : The developer writes the code for the system.

Testing and Review : Developers run all modules in a test environment to evaluate the accuracy and stability of the code.

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

Maintenance : Developers evaluate and modify the system to ensure that it performs its intended function.

Armed with the foundation of this basic development cycle, we can now gain insight into the considerations at each step that affect the security of smart contracts. The diagram below maps the factors that need to be considered to the relevant development stages. It should be noted that some steps in the link have multiple security considerations: 

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

As shown above, the software development life cycle does not always follow a linear path. In practice, overlapping or extending to other stages may occur. Some steps may need to be repeated in each release. Some tasks—such as testing and security reviews—may need to be performed from start to finish.

The software lifecycle and corresponding security considerations described above provide useful foundational information for promoting smart contract security, but we will examine them in more detail below to make understanding, applying, and sharing these practices as easy as possible Simple and specific analysis of 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 a specific approach to identifying and prioritizing potential threats to the system from the very beginning of the development lifecycle – smart contract developers should identify all security controls to be implemented in development and which should Check all threat testing, auditing and monitoring. 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 singularity 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, then it should work with a security consultant early in the design phase. Design your system with an “attacker” mentality and assume that any individual, hardware, or service can be attacked.

Security Considerations During Development

Consider management and access control

What: Implementing access controls, restricting permissions for privileged accounts and smart contracts calling special functions that perform administrative tasks (such as upgrading contracts and setting special parameters). Follow the “principle of least privilege”: each participant should have only the minimum required access.

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

How: Build a multi-signature wallet or DAO contract that is transparent to changes to the protocol and should go through a thorough review process as well as time locks (deliberately delayed and with the ability to cancel) to ensure that they can be verified for correctness and occur when they occur Rollback when governance attacks . Ensure that privileged keys are in a self-hosted wallet or secure escrow service and can be securely stored and accessed.

Consider integrating reusable, proven templates

What: Leverage existing smart contract standards as much as possible (e.g. OpenZeppelin Contracts ) and evaluate possible security issues that you might need to integrate with existing protocols.

Why: Using existing battle-tested, community-vetted standards goes 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 security audited trusted contract libraries and interfaces, after all Crypto and Web3 focus on open source, reuse and composability . Be sure to document your contract dependencies and their versions in the codebase, and minimize the resource footprint of your code; for example, import specific submodules of large projects instead of everything; understand your risk exposure so you can monitor Attacks; use official interfaces to call external protocols and ensure that potential integration risks are considered; monitor updates and security disclosures of contracts you reuse.

Security Considerations for the Test and Review Phase

Consider tests and project documentation

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

Why: Writing assumptions for expected behavior not only helps ensure that 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. The test suite should include mechanism design tests to examine the project’s token economics under extreme market scenarios, as well as unit and integration tests.

How: Tests with known testing frameworks and security checking applications – such as Hardhat ,  Mythril ,  Slither Truffle , etc.; provides different testing techniques such as fuzzing, property-checking, and even formal verification (formal verification); fully document your code, using NatSpec annotations to specify expected side effects, parameters, and return values. Generate real-time documentation with documentation generation tools and advanced design instructions. 

Consider internal reviews and security audits

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

Why: Shift from feature development to security issues to give 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 doesn’t have.

How: At an appropriate point in project development, schedule feature freezes to allow time for an internal review followed by an external audit. These actions should be done prior to live deployments and upgrades, check out guides from ConsenSys Nascent OpenZeppelin , and Trail of Bits that provide developers with a checklist of considerations — including timing — for anyone preparing for an 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 incentivizing white hat community engagement

What: Create programs that encourage community participation in security improvements to open source codebases. One way is to set up bug bounties. Another approach is to encourage the community to develop protocol monitoring and detection bots.

Why: Development teams can benefit from a wider range of knowledge and experience (similarly, open source helps Crypto grow). It’s worth noting that such programs can help fuel developers’ enthusiasm for the project, essentially turning the community and white hat hackers into evangelists. They can also help turn would-be attackers into guardians by giving hackers a way to become defenders.

How: Use a bug bounty platform (such as Code4rena HackenProof Immunefi , or Secureum ) to provide a bounty system with severity-based rewards to incentivize skilled hackers to disclose vulnerabilities. (Disclosure: Some of the co-authors of this article work for Forta , which has a network that provides a token incentive structure for creating decentralized high-quality security surveillance bots.) Development teams can encourage their protocol communities to leverage traditional and Web3-native approaches to incentivize the hunt for bugs and give participants potential rewards for enhancing security, resulting in 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 development teams and the 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 may seem easy to think of, but may be overlooked in planning.

How: Use monitoring platforms or distributed nodes to run bots that monitor smart contract events in real time. Build dashboards and alert notifications as needed for development teams and the wider community.

Consider Incident Emergency Response Processes

What: Leverage tools and processes that respond immediately to any security issue.

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

How: Prepare for the worst by planning how to respond to an incident or emergency and automating your response capabilities to the greatest extent possible. This includes assigning investigation and response responsibilities to competent individuals who can publicly contact those related to security issues through a distributed security mailing list, instructions in code repositories, or a smart contract registry. Based on the agreed threat model, develop a set of processes that may include scenario exercises and expected response times for emergency action. Consider integrating automation into incident response: for example, tools can receive events from Forta bots 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 sufficient to provide an exhaustive discussion of all aspects of smart contract security. Teams lacking 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 more than just ticking off a simple checklist to manage complex issues, it is always a never-ending, continuous process of practice. We are still in the beginning stages of establishing these practices, so now is the time to collaboratively create and share security practices for all developers.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/a16z-how-to-build-a-development-process-that-improves-smart-contract-security/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-06-08 10:27
Next 2022-06-08 10:29

Related articles