a16z: A Security Guide for Smart Contracts in Web3 Projects
By following these 8 points, you can maximize the prevention of hacker attacks.Source: a16z
Compiled by: Katie Gu, Planet Daily
Typically, hackers discover and exploit vulnerabilities throughout the entire software development lifecycle (from design to deployment to maintenance), thereby breaking the security barriers of blockchain projects. If relevant experiences could be known in advance, I believe there would be significantly fewer security incidents.
This article outlines the security factors that Web3 developers and security teams must consider when designing, developing, and maintaining smart contracts, covering the entire cycle from threat modeling to incident response preparedness.
Developing secure software includes the following five stages:
Design: Developers describe the required functionalities and operations of the system, including important benchmarks and fixed attributes;
Development: Developers write the system code;
Testing and Review: Developers gather all modules in a testing environment and assess their correctness, scalability, and other factors;
Deployment: Developers put the system into production;
Maintenance: Developers evaluate and modify the system to ensure it performs the intended functions.
The diagram below correlates the security factors that need to be considered with the stages mentioned above.
It is important to note that the software development lifecycle does not always follow a linear path: categories may overlap or extend into other stages. For each version, steps may be repeated. Some security tasks (such as testing and security reviews) may need to be continuously enforced.
The software lifecycle steps described above and the corresponding security considerations provide a foundation for promoting the security of smart contracts. The following will delve into three questions for a more detailed study.
1. Security Considerations in the Design Phase ------ Consider Threat Modeling and Secure Design
Content: Clearly identifying potential threats to the system and prioritizing them from the early stages of the project development lifecycle is crucial. Smart contract developers should identify all security controls to be implemented during development and the threats to be checked during testing, auditing, and monitoring. All security assumptions, including the expected complexity and economic means of attackers, should be clearly defined and articulated during the design phase.
Reason: While it is tempting for developers to focus solely on the intended use of the smart contract or protocol, this singular focus may leave them with "blind spots" that can be exploited by attackers.
Method: Follow established threat modeling practices. If a development team lacks internal security experts, they should engage with security consultants early in the design phase. Adopt an "attacker" mindset when designing the system and assume that any individual, machine, or service could potentially be attacked.
2. Security Considerations in the Development Phase ------ Management Considerations and Access Control
Content: Implement access controls that restrict the ability to perform management tasks (such as upgrading contracts and setting special parameters) on privileged accounts and smart contract calls. Follow the "principle of least privilege" ------ each participant should only have the minimum access necessary.
Reason: By maintaining protocols through upgrade and governance processes, developers can improve the protocol by adding new features, patching security issues, and addressing changing conditions. If the ability to upgrade is not properly controlled, it could pose a serious security vulnerability.
Method: Establish multi-signature wallets or DAO contracts to transparently represent community-managed changes. Changes should undergo a thorough review process and set a time lock (deliberately delaying the establishment of regulations with the ability to cancel) to ensure that correctness can be verified and rolled back in the event of governance attacks. Ensure that privileged keys can be securely stored and accessed in self-custodied wallets or secure custody services.
3. Consider Reusable, Battle-Tested Templates and Integrations
Content: Leverage existing smart contract standards (such as OpenZeppelin contracts) whenever possible and assess the security assumptions of any protocol integrations that may need to occur with existing protocols.
Reason: Utilizing existing, battle-tested, community-audited standards and implementations significantly helps in reducing security risks. Evaluating the risks of protocol integrations aids in developing security checks to prevent attacks on external components (such as oracle manipulation).
Method: Import trusted contract libraries and interfaces that have undergone security audits. The focus of Web3 is on open-source usage, reusability, and composability. Ensure that contract dependencies and their versions are documented in the codebase, minimizing code footprint where possible. For example, import specific submodules of large projects instead of importing everything. Understand your risk exposure and monitor for supply chain attacks. Use official interfaces to call external protocols and ensure that potential integration risks are considered. Monitor updates and security disclosures of reused contracts.
4. Security Considerations in the Testing and Review Phase ------ Consider Testing and Documentation
Content: Create clear, comprehensive code documentation and establish a fast, thorough, and easy-to-run testing suite. Where possible, establish testing environments on testnets or simulate mainnet conditions for deeper experimentation.
Reason: Writing assumptions about the expected behavior of the codebase helps ensure that risks in the threat model are addressed and that users and external auditors can understand the intentions of the development team. Creating a testing suite for the code helps validate (or refute) development assumptions and encourages deeper thinking about the threat model. This testing suite should include mechanism design tests for the project token economics under extreme market scenarios, as well as unit tests and integration tests.
Method: Implement known testing frameworks and security checkers, such as Hardhat, Mythril, Slither, Truffle, etc., which provide various testing techniques like fuzzing, property checking, and even formal verification. Use NatSpec comments extensively to document the code, specifying expected side effects, parameters, and return values. Utilize documentation generation tools and high-level design specifications to produce live documentation.
5. Consider Internal Reviews and Security Audits
Content: Take the time to discover vulnerabilities through internal and external code reviews.
Reason: Shifting focus from feature development to security issues gives developers time to uncover potential edge cases. External audits play a particularly important role in this regard, as they can provide perspectives and expertise that the development team may lack.
Method: Freeze certain functionalities at appropriate points in the project development to allow time for internal reviews, followed by external audits. This should be done before any actual deployments and upgrades.
Refer to the guidelines from ConsenSys, Nassent, OpenZeppelin, and Trail of Bits, which provide developers with checklists of considerations, including timelines, for anyone preparing for an audit. Also, ensure to review deployment transactions to confirm they use audited code versions and have appropriate parameters, especially when upgrading software.
6. Security Considerations in the Deployment and Maintenance Phase ------ Incentivize White Hat Community Participation
Content: Create programs that encourage community involvement in the security improvement of open-source codebases. One method is to create a bug bounty program. Another method is to encourage the community to develop protocol monitoring detection bots.
Reason: Development teams can benefit from a wide range of knowledge and experience (which is also the role of open source in the crypto space). Such programs can help spark enthusiasm for a project, essentially turning the community and white hat hackers into advocates. By providing hackers with a pathway to become defenders, they can also help transform potential attackers into security assets.
Method: Use bug bounty platforms (such as Code4rena, HackenProof, Immunefi, or Secureum) to incentivize skilled hackers to disclose vulnerabilities safely.
Note: Some authors in this article work for Forta, a network that provides a tokenized incentive structure for creating high-quality security monitoring bots for decentralized applications. Development teams can encourage their protocol communities to utilize both traditional and Web3-native methods to incentivize bug bounties and potentially profit participants through enhanced security, achieving a win-win situation.
7. Real-Time Monitoring Security Considerations
Content: Implement systems to monitor smart contracts and critical operational components (such as oracles and cross-chain bridges) and report suspicious activities to the development team and community based on known threat models.
Reason: Early detection of issues allows teams to respond quickly to vulnerabilities, potentially preventing or mitigating any losses.
Method: Use monitoring platforms or run bots on distributed nodes to monitor smart contract events in real-time. Insert data dashboards and alert notifications for the development team and the broader community as needed.
8. Security Considerations for Incident and Emergency Response Operations
Content: Utilize tools and processes that can respond immediately to any security issues that arise.
Reason: Even with the best pre-deployment safeguards, smart contracts and critical components (such as oracles and cross-chain bridges) can still encounter real-time issues. Having dedicated personnel, clear processes, and appropriate automation ensures that events can be investigated quickly and resolved as soon as possible.
Method: Prepare for the worst-case scenario by planning how to respond to incidents or emergencies, automating response capabilities as much as possible. Include responsibilities for investigation and response, allowing personnel to publicly contact security issues through distributed security mailing lists, instructions in code repositories, or smart contract registries. Develop a set of processes based on the protocol's threat model, which may include scenario drills and expected response times for taking emergency actions, considering integrating automation into incident response.
Security considerations should be an integral part of successful development, not just an afterthought or an add-on. While this framework shares some quick guidelines for building Web3 protocols and applications to promote security throughout the development process, no brief overview can comprehensively discuss smart contract security. Teams lacking internal security expertise should reach out to qualified Web3 security experts who can guide and assist in applying these practices to their specific situations.
Remember, security is not a simple issue. Security will always be a set of never-ending, ongoing best practices. We are still in the early stages of establishing these practices, and now is the time for all developers to collaborate in creating and sharing them.
