Our previous blog post, Defining the Web3 Security Maturity Model, outlined the assessment framework that Web3 projects can use to evaluate their current level of security maturity within the Web3 Secure Development Life Cycle (SDLC). Additionally, we defined the Security Maturity Model (SMM) subdomains and criteria for the Design and Develop phases of the Web3 SDLC. In this post, we'll outline the SMM of the Deploy phase. As a quick recap, the Deploy phase of the Web3 SDLC encompasses deployment and governance administration, data management, the deployment process, and pre-/post-deployment testing of all on-chain and off-chain components for a Web3 project.

The Deploy phase consists of three subdomains, where each subdomain contains its own relevant criteria: Administration and Data Management, Deployment Automation, and Verification and Testing.

For each subdomain, we’ll identify who the relevant stakeholders are for accessing and acting on each criterion. We will also define each subdomain and criteria, and explain the rationale for why they were chosen.

Administration and Data Management

Administration and data management refers to where and how deployment data, sensitive information, and private keys are stored, in addition to the processes used to administer smart contracts. For projects with governance components, administration also refers to the process of formalizing the roles and responsibilities of key stakeholders. Adhering to the criteria within this subdomain can help prevent accidental leakage of sensitive information or even private keys, enables developers to easily locate relevant deployment artifacts, and ensures a consistent, orderly process for smart contract administration, whether through governance or not. The following criteria are directed towards the individuals in a company that are responsible for product development, development operations (DevOps), and individuals who will play an active role in the governance operations of a protocol, if applicable.

Sensitive Information Storage

  • Definition: The location where sensitive information that are not private keys are stored, and the protections in place that help prevent unauthorized access. In this context, sensitive information refers to credentials and other secrets that may be necessary for the deployment of on- and off-chain components. An example of an off-chain deployment secret would be API keys required for monitoring platforms.
  • Rationale: The protection of sensitive information ensures that the supporting components around a smart contract are secure, and helps prevent accidental data leakage that could compromise the security of on- and off-chain components.

Maturity Level

  • Minimum: Sensitive information that is not a private key is stored in a local file.
  • Improved: Sensitive information that is not a private key is stored in a password-protected file with access control restricted.‍
  • Advanced: Sensitive information that is not a private key is stored in a secrets manager or vault.

Private Key Storage

  • Definition: The location and medium where deployment private keys are stored. Location can be local or remote, and medium refers to how the private key is held. The different mediums for storing private keys include hot wallets, cold wallets, or using a dedicated key management platform.
  • Rationale: The secure storage of deployment private keys is a vital component of ensuring the security of deployed smart contracts, and by extension, user assets.

Maturity Level

  • Minimum: Deployment private keys are kept in a local environment variable (.env) file.
  • Improved: Deployment private keys are kept separately in a hot wallet.‍
  • Advanced: Deployment private keys are kept separately in a cold wallet, or key management platform.

Artifacts Management

  • Definition: The location and ease with which deployment artifacts can be retrieved. Location can be local or remote, and ease refers to whether deployment artifacts can be easily identified per-version and accessed by external users. Deployment artifacts include compiled source code, smart contract ABIs, and other materials generated as part of the deployment of off-chain components.
  • Rationale: Having versioned, publicly available on- and off-chain deployment artifacts ensures transparency for users and allows them to interact with the various components of a protocol at any point in time.

Maturity Level

  • Minimum: Artifacts from deployment are stored locally.
  • Improved: Artifacts from deployment are pushed to version control, overwriting previous versions.‍
  • Advanced: Artifacts are tagged and pushed into version control without overwriting previous versions, or are pushed to an artifact management platform. Artifacts are publicly available and documented.

Governance Management

  • Definition: The naming of relevant stakeholders who will participate in governance functions, the assignment of roles and responsibilities for each stakeholder, and the finalizing of processes for stakeholders interacting with governance functions. This criterion is only required for protocols that have governance components.
  • Rationale: Identifying privileged stakeholders that have the ability to interject into specific phases of a governance process helps ensure transparency to users. Additionally, outlining which stakeholder is responsible/able to influence what part of the governance process, and having clear processes for if and when they should interject into the process ensures that stakeholders act when they are supposed to, and do not act when they are not supposed to.

Maturity Level

  • Minimum: Relevant stakeholders for governance have been publicly named. Relevant stakeholder information can be found in public documentation.
  • Improved: Roles and responsibilities have been finalized, documented, and assigned to relevant stakeholders.‍
  • Advanced: Processes related to governance management have been defined and assigned to relevant stakeholders.

Smart Contract Administration

  • Definition: The process and medium used for managing deployed smart contracts. This can include actions such as adjusting protocol parameters, calling administrative functions, withdrawing protocol fees, and more.‍
  • Rationale: Having consistent, documented manual and automated management procedures help to ensure protocol management functions execute reliably and as expected. Contract management procedures increase the speed at which changes can be applied, which is critical for emergency management.

Maturity Level

  • Minimum: Smart contract administration is initiated manually. Administrative actions are performed manually.
  • Improved: Documentation exists and clearly states when administration will be performed. Administrative actions are automated.‍
  • Advanced: Smart contract administration is fully automated and initiated programmatically when the documented conditions have been met.

Deployment Automation

Deployment automation refers to the processes and mediums used for deploying and upgrading smart contracts. There is also criteria solely for upgrades that have a governance component, as well as the process for deploying relevant off-chain components. Having a consistent, automated upgrade and deployment process can prevent deployment failures and other issues from occurring. This in turn can help reduce the likelihood of security vulnerabilities during deployments. The following criteria are directed towards the individuals in a company that are responsible for product development and DevOps.

Smart Contract Deployment

  • Definition: The medium for deploying smart contracts to the blockchain. This refers to how smart contracts are deployed, whether manually or through various forms of automation.
  • Rationale: Having automation in smart contract deployments helps prevent user error from introducing security vulnerabilities. Having standardized, easy-to-read automation further guards against security vulnerabilities caused during deployment.

Maturity Level

  • Minimum: Smart contracts are deployed manually via an IDE.
  • Improved: Smart contract deployments are automated in a script.
  • Advanced: Smart contracts are deployed via predefined configuration as code templates or using an infrastructure platform.

Deployment Process

  • Definition: The automation of the deployment process itself, which is relevant to both on- and off-chain deployments. Automation levels range from manually initiating each step in a deployment to a fully automated deployment process initiated as part of Continuous Integration-Continuous Development (CI-CD) workflows.
  • Rationale: Having an automated deployment process helps ensure that all relevant components are updated when new features are added, which can help prevent bugs and security vulnerabilities. Additionally, automated deployment processes increase the speed with which updates can be applied to a project, which is vital when security vulnerabilities need to be patched.

Maturity Level

  • Minimum: Deployment steps are manually and individually initiated.
  • Improved: Deployment steps are automated in a script.
  • Advanced: Deployment steps are handled by a CI-CD pipeline.

Smart Contract Upgrade Process (excludes Governance)

  • Definition: The process and medium used for upgrading smart contracts, which includes pre- and post-upgrade deployment as well as the upgrade deployment process itself. This criteria also encompasses manual and automatic verification of upgrades as part of the process. Governance is excluded from this criteria and has its own separate criteria for upgrades.
  • Rationale: Having an automated smart contract upgrade process that uses standardized libraries built for upgrades can help ensure the success of smart contract upgrades, and can otherwise provide early indications of upgrade failures before they result in security vulnerabilities.

Maturity Level

  • Minimum: Smart contract upgrade process is automated in a script.
  • Improved: Upgrade process includes pre and post-deployment verification scripts.
  • Advanced: Smart contract upgrade process makes use of standard packages/ libraries to handle changes.

Governance Upgrade Process

  • Definition: The process used for upgrading or changing properties of smart contracts that are controlled via governance. This includes identification of relevant proposal steps, generating minimum requirements for valid proposals, and automated generation and testing of proposal submissions.‍
  • Rationale: Creating a well-defined and constrained proposal process helps ensure successful proposals. Automated generation and verification of proposal submissions also helps prevent incorrect or malicious proposals from making it into the voting process.

Maturity Level

  • Minimum: Proposal requirements and creation steps are clearly defined and consistent.
  • Improved: Proposal submissions are verified against base requirements and unit tests.
  • Advanced: Proposal submission generation is fully automated and verified against base requirements and unit tests. Proposal submissions are required to go through the automated process.

Verification and Testing

Deployment verification and testing refers to the processes of verifying source code used in deployment, and performing tests against contract deployments in order to ensure correct pre- and post-deployment behavior. There is also criteria specific to ensuring the integrity of smart contracts during upgrades, if applicable. Having a comprehensive test suite for deployment and tests that directly simulate the network conditions of the blockchain being deployed reduces the likelihood of security vulnerabilities caused during deployment. The following criteria are directed towards individuals in a company that are responsible for product development and DevOps.

Source Code Verification

  • Definition: The process and code required to verify smart contract deployments. Verification typically entails providing exact source code that, when compiled, is equivalent to the smart contract(s) deployed to the blockchain.
  • Rationale: Ensuring smart contract deployments are verified helps users identify the correct contract to use. Additionally, should external platforms used for verification stop working, having the means to retrieve the exact on-chain source code ensures users can still successfully interact with the smart contracts.

Maturity Level

  • Minimum: Smart contract source code is verified manually after deployment.
  • Improved: Smart contract source code is verified automatically as part of the deployment process.
  • Advanced: Smart contract source code is verified automatically and tagged in version control and is publicly available to ensure verification can be replicated.

Upgrade Integrity and Verification

  • Definition: The process for verifying smart contracts’ integrity post-upgrade. Verification encompasses both checking that a smart contract’s state has not been corrupted and that the smart contract continues to work as expected post-upgrade.
  • Rationale: Verifying upgrades of smart contracts is vital to ensuring no security vulnerabilities have been introduced as part of the upgrades. Using automated verification also removes human error from incorrectly verifying smart contract upgrades.

Maturity Level

  • Minimum: Smart contract upgrades are manually checked to ensure an upgrade will not negatively impact the smart contract(s).
  • Improved: Smart contract upgrades are checked using upgrade-specific libraries/ packages, or using custom scripts.
  • Advanced: Smart contract upgrades are handled with upgrade-specific libraries/packages. Smart contract upgrades are simulated locally and tested using a custom suite of regression tests.

Integration Testing and Simulations

  • Definition: The tests and blockchain simulations created to ensure smart contract deployments will be successful. While other criteria encompass pre- and post-deployment stages, this criteria specifically occurs during pre-deployment of smart contracts and smart contract upgrades. Tests and simulations can range from creating deployment integration tests to simulating complex smart contract deployments with local RPC nodes, forked from the most recently mined block, that can accurately simulate the on-chain network conditions.‍
  • Rationale: Having integration tests and simulating smart contract behavior before deployment helps ensure successful smart contract deployments and upgrades. This helps prevent unexpected failures that may not be caught with unit tests and mocking frameworks that may not accurately represent on-chain conditions.

Maturity Level

  • Minimum: Smart contract deployments are run through a development test suite.
  • Improved: Smart contract deployments are first deployed to a testnet environment and run through an on-chain development test suite.
  • Advanced: Smart contract deployments are simulated with local RPC nodes forked from the relevant network, and are run through a custom suite of integration and development tests.

Why You Can Trust Arbitrary Execution

Arbitrary Execution (AE) is an engineering-focused organization that specializes in securing decentralized technology. Our team of security researchers leverage their offensive security expertise, tactics, techniques, and hacker mindset to help secure the crypto ecosystem. In the two years since the company’s inception, Arbitrary Execution has performed more than 40 audits of Web3 protocols and projects, as well as created tools that continuously monitor the blockchain for anomalous activity. For more information on Arbitrary Execution's professional services, contact info@arbitraryexecution.com. Follow us on Twitter and LinkedIn for updates on our latest projects, including the Web3 SDLC.