How to define a scope for DeFi app?

The most effective way to assess whether a system component falls within scope is through an example. Here, we will examine the infrastructure of an imaginary DeFi product, a model that—with minor modifications—can represent most DeFi products.

Imaginary DeFi product infrastructure

This DeFi product performs two critical functions:

• Providing Transaction Data: Supplying users with essential data required for transaction.

• Managing User Funds: Applying product's logic to user's funds on smart contract.

By analyzing these core functions, we can systematically determine which components are in scope based on their impact on assets security. In this model, the DeFi product manages user funds, making financial security the primary concern.

The key threat is theft of user funds, which can occur through two main attack vectors:

1. Smart Contract Exploits

2. Malicious Transactions

How can these threats materialize?

1. Smart Contract Exploits: An attacker can create exploit for vulnerabilities in the smart contract’s code.

2. Malicious Transactions: An attacker can deceive users into signing fraudulent transactions by providing manipulated calldata.

For an attacker to inject malicious calldata, they must gain access to:

• Systems that process transaction data (e.g., backend services, API endpoints).

• Communication channels that transmit transaction data (e.g., web interfaces, network protocols).

So, as result, the following components and connections are in scope:

• smart contract

• Blockchain node

• Channel between blockchain node and backend

• backend server

• channel between web server and backend

• web server

• channel between web server and users's app

• users's app

If an attacker will gain access to manipulate data in this systems and channels, then user's funds are at significant risk and almost for sure will be stolen.

While this analysis provides a structured approach to understanding scope, a simpler framework can be used to determine whether a component should be considered in scope. If the answer to any of the following questions is YES, then the component is in scope:

1. Does the component process any information that the user is about to sign? Example: Calldata generation and transmission.

2. Does the component contain any logic that processes user funds? Example: Smart contracts handling fund transfers.

3. Does the component process any information used in managing user data? Example: Oracles providing external data inputs.

4. Does the component handle production source code storage or delivery? Example: CI/CD pipelines, Git repositories.

By applying this framework, security assessments can quickly and effectively determine which components are in scope.