a16z: Smart Contract Security Guidelines for Web3 Projects

Often, hackers find and exploit flaws in the entire chain of software development, from design to deployment to maintenance, to break the security barriers of blockchain projects. If I can learn about the relevant experience in advance, I believe that there will be many 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 preparedness .

Developing a secure software consists of the following five stages:

  1. Design: The developer describes the required functionality and operation of the system, including important benchmarks and fixed properties;
  2. Development: developers write system code;
  3. Testing and reviewing: developers bring together all modules in a test environment and evaluate them for correctness, size, and other factors;
  4. Deployment: The developer puts the system into production;
  5. Maintenance: Developers evaluate and modify the system to ensure that it performs its intended function.

The following diagram maps the security factors to be considered with the above phases.

a16z: Smart Contract Security Guidelines for Web3 Projects

It is important to note that the software development life cycle does not always follow a linear path: categories may overlap or extend into other phases. Steps may be repeated for each release. Some security tasks, such as testing and security reviews, may require follow-through.

The software lifecycle steps and corresponding security considerations described above provide the basis for promoting smart contract security. The following three questions will be discussed in more detail.

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

  • What: Clearly identifying and prioritizing potential threats to the system from the very beginning of the project development life cycle is key. Smart contract developers should identify all security controls to be implemented in development, as well as threats that should be checked in testing, auditing, and monitoring. All security assumptions, including the expected level of sophistication and economic means of attackers, should be clearly defined and articulated during the design phase.
  • Why: While it’s tempting for developers to focus only 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.
  • Approach: Follow known threat modeling practices. If a development team does not have in-house security experts, it should engage with security consultants early in the design phase. Design your system with an “attacker” mentality and presuppose situations where any individual, machine, or service can be attacked.

2. Security Considerations at the Development Stage – Administrative Considerations and Access Control

  • What: Implement access controls that limit the ability to invoke special functions for privileged accounts and smart contracts 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.
  • Why: By upgrading and maintaining the governance process, developers can improve the protocol by adding new features, patching security issues, and addressing changing conditions. This could constitute a serious security breach if the ability to upgrade is not properly controlled.
  • 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 with a time lock (deliberately delaying the formulation of regulations with the ability to cancel) to ensure that they can be verified for correctness and rolled-back in the event of a governance attack. Ensure that privileged keys are securely stored and accessible in a self-custody wallet or safekeeping service.

3. Consider reusable, battle-tested templates and integrations

  • What: Leverage existing smart contract standards (such as OpenZeppelin contracts) wherever possible, and evaluate security assumptions that may require protocol integration with existing protocols.
  • Why: Using existing battle-tested, community-audited standards and implementing measures to mitigate security risks can go a long way. Assessing the risks of protocol integration helps develop security checks to prevent attacks on external components such as oracle manipulation.
  • Approach: Import security audited trusted contract libraries and interfaces. Web3’s focus is on open source usage, reusability, and composability. Make sure to document contract dependencies and their versions in the codebase to minimize code footprint as much as possible. For example, import a specific submodule of a large project, instead of importing everything. Understand your risk exposure and monitor supply chain attacks. Use official interfaces to call external protocols and make sure to take into account potential integration risks. Monitor reused contracts for updates and security disclosures.

4. Security Considerations During Testing and Review Phases – Consider Testing and Documentation

  • What: Create clear, comprehensive code documentation and build a test suite that is fast, thorough, and easy to run. When allowed, build a test environment on the testnet or through the mainnet simulation to conduct more in-depth experiments.
  • Why: Writing assumptions about the expected behavior of the codebase helps ensure that risks in the threat model are addressed and that the intent of the development team is understood by users and external auditors. Creating test suites for code can help prove (or disprove) development assumptions and encourage deeper thinking about threat models. This test suite should include mechanism design tests to examine the project’s token economy in extreme market scenarios, as well as unit and integration tests.
  • Approach: Implement known testing frameworks and security checkers like Hardhat, Mythril, Slither, Truffle, etc. that provide different testing techniques like fuzzing, property checking, and even formal verification. Use NatSpeccomments to document code extensively, specifying expected side effects, parameters, and return values. Generate real-time documentation using documentation generation tools along with advanced design instructions.

5. Consider internal reviews and security audits

  • What: Take the time to find vulnerabilities through internal and external code inspections.
  • Why: Shifting from feature development to focusing on security issues gives developers time to uncover potentially obscure issues. External audits are especially useful here, as they can bring an outside perspective and expertise that the development team doesn’t have.
  • Approach: Freeze a feature at an appropriate point in project development to allow time for an internal review, followed by an external audit. This should be done before any actual deployments and upgrades.

Check out the guides from ConsenSys, Nassent, OpenZeppelin, and Trail of Bits, which provide developers with a checklist of things to consider, 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 proper parameters, especially when upgrading software.

6. Security Considerations During Deployment and Maintenance Phases – Incentivizing White Hat Community Engagement

  • What: Create programs that encourage community participation in security improvements to open source codebases. One way is to create bug bounties. Another approach is to encourage the community to develop protocol monitoring and detection bots.
  • Why: Development teams can benefit from a wide range of knowledge and experience (this is what open source does in crypto). Such programs can help generate enthusiasm for a project, essentially turning the community and white hat hackers into evangelists. They can also help turn potential attackers into security assets by giving hackers a way to become defenders.
  • Approach: Use a bug bounty platform such as Code4rena, HackenProof, mmunef, or Secureum to incentivize skilled hackers to safely disclose vulnerabilities.

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 bots. 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.

7. Real-time monitoring security considerations

  • 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 quickly respond to breaches, potentially preventing or mitigating any losses.
  • Method: Use a monitoring platform or distributed nodes to run robots to monitor smart contract events in real time. Insert data dashboards and alert notifications as needed for development teams and the wider community.

8. Safety Considerations for Accident and Emergency Response Operations

  • What: Use tools and processes that respond immediately to any security issue.
  • Why: Even with the best pre-deployment safeguards, real-time issues can still occur with smart contracts and key components such as oracles and cross-chain bridges. Having dedicated staff, clear processes and appropriate automation equipment ensures incidents can be investigated quickly and resolved as quickly as possible.
  • Approach: Prepare for the worst, plan how to respond to an incident or emergency, and automate response capabilities to the greatest extent possible. This includes assigning responsibility for investigations and responses, who can be contacted publicly about security issues through a distributed security mailing list, instructions in code repositories, or a smart contract registry. Based on the protocol’s threat model, develop a set of processes that can include scenario rehearsal and expected response time required to take emergency action, and integration of automation into emergency response can be considered.

Security considerations should be an integral part of successful development, not just an afterthought or supplement. While this framework shares some quick guides for building Web3 protocols and applications that promote security throughout the development process, there isn’t any brief overview that can cover all aspects of smart contract security. Teams lacking in-house security expertise should contact qualified Web3 security experts who can guide and help apply to their specific situation.

Remember, security is not a simple issue. Security will always be a never-ending, continuous set of best practices. We’re still in the early stages of establishing these practices, and now is the time to create and share them collaboratively for all developers.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/a16z-smart-contract-security-guidelines-for-web3-projects/
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:33
Next 2022-06-08 10:35

Related articles