> For the complete documentation index, see [llms.txt](https://checklist.dfsf.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://checklist.dfsf.org/scope/how-to-define-a-scope-for-defi-app.md).

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

<figure><img src="https://3439198811-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3hSm3sRNGWbNlcQHXjqH%2Fuploads%2FqVJxI7EwuPEsmFtIVdnP%2FScreenshot_2025-02-05_09-25-30.png?alt=media&amp;token=95b51262-79d2-43f2-b78a-228bcac0ce97" alt=""><figcaption><p>Imaginary DeFi product infrastructure</p></figcaption></figure>

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&#x20;

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.

### Model

We have now examined a specific example at an intuitive level. To avoid confusion—which is very common when working with other systems—it is best to use a model that clearly distinguishes between threats, vulnerabilities, and risk.\
\
**Vulnerability** — a weakness in an asset or control that *could* be exploited. It exists whether or not anyone is trying to exploit it. Vulnerabilities are properties of your environment.

**Threat** — something or someone with the potential to exploit a vulnerability. A threat exists independently of your environment. You don't create threats; you discover that they exist in the world.

**Impact** — The damage you get  on threat release.&#x20;

**Risk** — the *combination* of a threat exploiting a vulnerability, expressed as likelihood × impact. Risk is what you actually manage, because it's the only one of the three that has a business consequence attached.

The formal relationship (from ISO 27005 and NIST SP 800-30):

> **Risk = Threat × Vulnerability × Impact**

No threat, no risk. No vulnerability, no risk. No impact, no risk. All three must be present.

Examples to understand the difference:

| Vulnerability                                           | Threat                                 | Risk                                                                                                                 |
| ------------------------------------------------------- | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Admin SSH allows password authentication                | Credential-stuffing botnets            | Botnet brute-forces an admin account and gains shell access, leading to full server compromise                       |
| No MFA on the cloud console                             | Phishing attackers targeting employees | Phished employee credentials are used to access AWS console, attacker spins up crypto miners and exfiltrates S3 data |
| Backups stored in the same region as production         | Regional cloud outage; ransomware      | Production and backups are simultaneously lost, causing multi-day outage and possible data loss                      |
| Third-party JS library hasn't been updated in 18 months | Supply chain attackers; published CVEs | Known CVE in the library is exploited to inject card-skimming code, leading to PCI breach                            |

<br>