This article comes from a16zcryptoThis article comes from

, original author: Andy Beal, Nassim Eddequouaq, Riyaz Faizullabhoy & Christian Seifert, compiled by Odaily translator Katie Ku.

Often, hackers will find and exploit flaws in the entire chain of software development processes (from design to deployment to maintenance), thus breaking the security barrier of blockchain projects. If the relevant experience can be learned in advance, I believe that there will be much fewer safety accidents.。

This article outlines the security elements that Web3 developers and security teams must consider when designing, developing, and maintaining smart contracts, covering the entire cycle from threat modeling to emergency response preparation

1. Developing a secure software consists of the following five phases:

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

3. Development: developers write system code;

4. Testing and review: developers gather all modules in a test environment and evaluate them for correctness, scale and other factors;

5. Deployment: developers put the system into production;

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

The diagram below maps the security factors that need to be considered to the above phases.

The software lifecycle steps and corresponding security considerations described above provide the basis for facilitating smart contract security. In the following, we will conduct more detailed research on three issues.

secondary title

• 1. Smart contract security considerations in the design phase - consider threat modeling and security design

• What: Clearly identifying and prioritizing potential threats to systems from early in the project development life cycle is key. Smart contract developers should identify all security controls to implement during development, and threats that should be checked for during testing, auditing, and monitoring. All security assumptions, including the expected sophistication and economic means of an attacker, should be clearly defined and articulated during the design phase.

• Why: While it’s tempting for developers to focus solely on the intended use of a smart contract or protocol, this sole focus can leave them with “blind spots” that can be exploited by attackers.Design systems with an "attacker" mindset and presuppose that any individual, machine, or service can be attacked.

secondary title

• 2. Security Considerations in the Development Phase - Administrative Considerations and Access ControlWhat: Implement access controls that limit the ability to privileged accounts and smart contract calls to 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 amount of access needed.

• Approach: Build a multi-signature wallet or DAO contract to transparently manage changes on behalf of the community. Changes should go through a thorough review process and have a time-lock (deliberately delaying the enactment of regulations with the ability to cancel them) to ensure their correctness can be verified and rolled-back in the event of a governance attack. Ensure that privileged keys are securely stored and accessible in a self-custodial wallet or safekeeping service.

secondary title

• 3. Consider reusable, battle-tested templates and integrations

• What: Leverage existing smart contract standards (such as OpenZeppelin Contracts) where possible, and assess the security assumptions that may be required for protocol integration with existing protocols.

• Why: Using existing battle-tested, community-audited standards and implementing measures to mitigate security risks can be of great help. Assessing the risks of protocol integration helps to develop security checks to prevent attacks on external components such as oracle manipulation.Know your risk exposure and monitor supply chain attacks. Use the official interface to call external protocols, and make sure to consider potential integration risks. Monitor updates and security disclosures for reused contracts.

secondary title

• 4. Security considerations during the testing and review phase - consider testing and documentation

• What: Create clear, comprehensive code documentation and build a test suite that's fast, thorough, and easy to run. Where possible, establish a test environment on the test network or simulate the main network to conduct more in-depth experiments.reason:Writing out assumptions about the expected behavior of the codebase helps ensure that risks in the threat model are addressed and that users and external auditors understand the development team's intent.

• Approach: Implement known testing frameworks and security checkers such as Hardhat, Mythril, Slither, Truffle, etc., which provide different testing techniques such as fuzzing, property checking, and even formal verification. Use NatSpec comments to extensively document your code, specifying expected side effects, parameters, and return values. Generate real-time documentation using documentation generation tools as well as high-level design instructions.

secondary title

• 5. Consider internal reviews and security audits

• What: Take the time to uncover vulnerabilities through internal and external code inspections.Why: Shifting from feature development to focusing on security issues gives developers time to spot potentially obscure issues.

• External audits are especially useful here, as they can bring outside perspective and expertise that the development team doesn't have.

Check out the guides from ConsenSys, Nassent, OpenZeppelin, and Trail of Bits, which provide developers with a checklist of considerations, including timing, for anyone preparing for an audit. Also make sure to check deployment transactions to make sure they use audited code versions and have appropriate parameters, especially when upgrading software.

secondary title

• 6. Security considerations in the deployment and maintenance phases - motivating white hat community participation

• What: Create a program that encourages community participation in security improvements to open source code bases. One way to do this is by creating bug bounties. Another approach is to encourage the community to develop protocols to monitor and detect bots.

• Why: Development teams can benefit from a wide range of knowledge and experience (this is also the role of open source in the field of encryption). Such a program can help spark enthusiasm for a project, essentially turning the community and white hat hackers into evangelists. They can also help turn would-be attackers into secure assets by giving hackers a way to become defenders.

Note: Some of the authors in this article work for Forta Corporation, which owns a network that provides a tokenized incentive structure for the decentralized creation of high-quality security surveillance robots. Development teams can encourage their protocol communities to leverage both traditional and Web3-native approaches to incentivize bug bounties and potentially benefit participants through enhanced security, a win-win situation.

secondary title

• 7. Real-time monitoring security considerations

• What: Implement a system that monitors smart contracts and key operational components such as oracles and cross-chain bridges, and reports suspicious activity to the development team and community based on known threat models.

• Method: Use a monitoring platform or distributed nodes to run robots to monitor smart contract events in real time. Plug in data dashboards and alert notifications for development teams and the wider community as needed.

secondary title

• 8. Safety considerations for accident and emergency response operations

• What: Use tools and processes that can respond immediately to any security issues as they arise.

• Reason: Even with the best pre-deployment safeguards, real-time issues with smart contracts and key components such as oracles and cross-chain bridges are still possible. Dedicated personnel, clear processes, and appropriate automation ensure incidents can be investigated quickly and resolved as quickly as possible.

Approach: Prepare for worst-case scenarios, plan how to respond to incidents or emergencies, and automate response capabilities to the greatest extent possible. This includes assigning responsibility for investigation and response, who can be contacted publicly about security concerns via distributed security mailing lists, instructions in code repositories, or smart contract registries. Based on the agreement's threat model, develop a set of processes that can include scenario rehearsals and expected response times needed to take urgent action. Integration of automation into emergency incident response can be considered.Security considerations should be an integral part of successful development, not just an afterthought or addition.

While this framework shares some quick guidelines for building Web3 protocols and applications that facilitate security throughout the development process, there isn't any short overview that can discuss smart contract security in its entirety. Teams that lack in-house security expertise should contact qualified Web3 security experts who can guide and help apply to their specific situation.