Web3 introduces an entirely new set of threat vectors. A non-exhaustive list of those most relevant to this product shape are identified below.

Overall Security Philosophy

The best way to go about securing a disparate threat surface is to deploy a defense-in-depth strategy. Defense-in-depth is a strategy commonly used in information security to create multiple layers of security such that the blast radius is minimized with fallback security layers if the initial layer is compromised. See Appendix A for an example of defense-in-depth used within the context of a consumer application.

Wallet Drainers

Wallet drainers leverage malicious smart contracts in combination with a fake or compromised website to lure the victim into signing transaction instructions that will transfer all the victim’s assets to the hacker. This exploit has become quite lucrative with known wallet drainer variants having stolen over $300 million in assets in 2023. Like the ransomware-as-a-service market, advanced persistent threat groups (APT Groups) are providing drainer-as-a-service affiliate models that allow subscribers access to the latest variants as well as resources like phishing kits or social engineering services.

Surface Area will deploy best in class pre-execution control providers like Wallet Guard or Blockaid by default. Such providers will simulate smart contracts in a controlled environment providing the user with validation that a transaction is benign. At scale, these security providers have enough data to use heuristics as well as machine learning to help validate whether a transaction is malicious or not directly on the client. In a multichain world, this is of the utmost importance since malicious smart contract implementations will have subtle differences per blockchain (e.g. programming languages, bytecode, and opcodes).

In this way, Surface Area will prioritize user security out-of-the-box minimizing any chance that a user interacts with a malicious smart contract through malicious airdrops, scam tokens, address poisoning, etc.

Bad actor commits code with an exploit

In a creator-driven model where users can submit a build to be used by an entire network of users there are likely to be bad actors. There are reputation and slashing guardrails in place to disincentivize that type of behavior, but having an added layer of security is paramount to the integrity of the platform. Builds that are submitted to Surface Area will undergo static analysis via automation as well as dynamic analysis with sandboxing capabilities as part of an exhaustive security review process. This strategy is akin to how the Google Play Store reviews new applications submitted to be on the Android mobile operating system.

Vulnerabilities in third-party dependencies

For a product like Surface Area, the threat of a security incident occurring within the software supply chain is perhaps one of the hardest types of threat to prevent. Proactive measures must be taken to minimize the overall attack surface especially when leveraging third-party software libraries. Surface Area will deploy best security practices can help mitigate such a risk:

• The Surface Area team will undergo a risk assessment with strict security requirements when determining the eligibility of direct dependencies to be used on the platform. Note there is a slight difference between this, and builds submitted by creators on the platform.
• All platform dependencies will be tracked and regularly scanned for vulnerabilities.
• Whenever possible, the Surface Area team will have open lines of communication with product development teams who directly contribute to the third-party components used in the platform. This also applies to creators.

On rare occasions, threat actors (usually APT Groups) will utilize a zero-day vulnerability, or a security vulnerability that is previously unknown or unaddressed. When a zero-day is in effect, response and mitigation plans are of the utmost importance. The SphereOne Security Team has an exhaustive list of security runbooks to help reduce the time to deploy a fix if such an issue were to occur. See the Appendix for an example of a security runbook.