How to Run Threat Modeling Sessions

Threat modeling is a systematic process for identifying, quantifying, and addressing security risks in a system. For DeFi protocols, which manage billions in user funds through immutable smart contracts, this proactive exercise is non-negotiable. A successful session moves the team from reactive patching to designing security in from the start. The core methodology involves four key questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good job? This guide outlines a practical, repeatable framework to answer these questions effectively.

Begin by defining the scope and creating a clear data flow diagram (DFD). For a DeFi protocol like a lending market, this involves mapping all actors (users, admins, oracles, other contracts), data stores (storage variables, external price feeds), processes (borrow, repay, liquidate), and trust boundaries (between EOAs and contracts, between your protocol and external dependencies). Use tools like draw.io or Miro. This visual artifact is critical—it creates a shared understanding of the system's architecture and surfaces all entry points an attacker could target, which is the first step in moving from abstract worry to concrete analysis.

With the DFD complete, conduct the threat identification phase. A proven technique is using the STRIDE framework, which categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. For each component in your diagram, ask STRIDE-based questions. For a price oracle: Can it be spoofed to provide false data? Can the data feed be tampered with? Could a flash loan cause a denial of service on a critical function? Document every potential threat in a threat registry, noting the vulnerable component, attack vector, and potential impact (e.g., "Theft of user collateral").

Next, prioritize the identified threats using a risk assessment model like DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or a simpler Impact/Likelihood matrix. A threat with high impact (total loss of protocol TVL) and high likelihood (reliance on a single admin key) must be addressed immediately. For each high-priority threat, brainstorm and document mitigation strategies. These can be technical (implementing a timelock for admin functions, adding circuit breakers), procedural (implementing a bug bounty program), or a decision to accept the risk. Assign each mitigation to an owner and a timeline.

Finally, integrate the findings into your development lifecycle. The output of a threat model should be actionable security requirements and test cases. For a mitigation like "prevent reentrancy," the requirement translates to using the Checks-Effects-Interactions pattern and the OpenZeppelin ReentrancyGuard. Update your audit scope to specifically test the identified high-risk areas. Threat modeling is not a one-time event; schedule follow-up sessions after major protocol upgrades, when integrating new external dependencies, or if the underlying risk landscape changes (e.g., a novel attack vector emerges in the ecosystem).

Before convening your team, clearly define the scope of the session. This includes specifying the target system, such as a new DeFi lending pool, a governance upgrade, or a cross-chain bridge component. Establish clear objectives: are you conducting a high-level design review, analyzing a specific attack vector like a flash loan exploit, or performing a final security audit before mainnet deployment? Document the system's architecture, including data flow diagrams (DFDs) that outline external entities, trust boundaries, data stores, and processes. Tools like draw.io or Miro can be used to create these visual aids.

Assemble a cross-functional team with diverse expertise. Essential participants include core protocol developers, a security engineer or auditor, a product manager to define business logic assumptions, and potentially a DevOps engineer familiar with deployment and key management. For blockchain-specific modeling, ensure at least one participant has deep knowledge of the underlying virtual machine (e.g., the EVM), common vulnerability patterns from the SWC Registry, and the economic incentives at play. Schedule a 2-3 hour block and use a structured methodology like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to guide the analysis.

Prepare the technical context for all attendees. Share the system's technical specifications, relevant smart contract addresses (on testnet), and any existing audit reports. If analyzing code, provide a link to the repository and highlight the specific files or functions in scope. Create a simple threat modeling template in a shared document or a dedicated tool like OWASP Threat Dragon. The template should have columns for: Threat Description, Affected Component, STRIDE Category, Potential Impact, and Mitigation Strategy. Setting these foundations ensures the session time is spent on analysis, not on basic questions.

A successful threat modeling session requires preparation. First, define the scope: is it a new smart contract, a governance upgrade, or a cross-chain bridge? Assemble a cross-functional team including developers, security researchers, and product managers. Prepare key artifacts: a data flow diagram (DFD) showing how assets and messages move between users, contracts, and external services, and a clear list of trust assumptions (e.g., "the oracle is assumed to be correct"). Tools like the OWASP Threat Dragon can help visualize the system. This upfront work ensures the session is focused and productive.

The core of the session is structured analysis using a framework like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). For each component in your DFD, systematically ask: "How could an attacker spoof this user's identity?" or "How could data in this storage slot be tampered with?" Document each potential threat. For a DeFi lending protocol, a Tampering threat might be: "An attacker could manipulate the price oracle to borrow assets without sufficient collateral." Rate each threat using a simple risk matrix (e.g., Likelihood x Impact) to prioritize follow-up actions.

The final, critical phase is translating threats into mitigations. For each high-priority threat, brainstorm and assign concrete countermeasures. These can be technical (e.g., "implement a decentralized oracle with fallback mechanisms"), procedural (e.g., "add a timelock for governance upgrades"), or monitoring-based (e.g., "create an alert for sudden TVL drops"). Assign each action to an owner and a timeline. Document everything in a living threat model, which should be revisited after major code changes or incidents. This creates a continuous security feedback loop, turning theoretical risks into managed, actionable items for your development roadmap.

Effective threat modeling is a proactive security exercise, not a one-time audit. The goal is to systematically deconstruct a system—like a DeFi protocol's PoolManager contract or a cross-chain bridge's relayer network—to uncover potential attack vectors before they are exploited. This process shifts security left in the development lifecycle, saving significant time and capital compared to post-deployment bug bounties or emergency responses. A successful session requires a cross-functional team including developers, architects, and product managers to ensure all perspectives on asset flows and trust boundaries are considered.

The first critical step is defining the scope and creating a data flow diagram (DFD). Clearly outline which components are in-scope: the core Vault.sol contract, the off-chain keeper bot, or the governance multi-sig. Then, map the data flows. Identify all external entities (users, oracles, other contracts), processes (key functions like deposit() or swap()), data stores (mappings, arrays), and trust boundaries (where control moves from an EOA to a contract, or from L1 to L2). Tools like draw.io or Miro are excellent for this collaborative visual mapping, which becomes the foundation for all subsequent analysis.

With the DFD complete, the team systematically applies a threat identification framework. The STRIDE model is particularly effective for blockchain systems: Spoofing (e.g., fake ERC-20 approvals), Tampering (manipulating contract storage), Repudiation (lack of non-repudiable logs), Information Disclosure (leaking private data via event logs), Denial of Service (gas griefing, locking funds), and Elevation of Privilege (unauthorized access to admin functions). For each element on the DFD, ask: "How could an attacker abuse this to achieve a STRIDE category?" Document every potential threat, no matter how unlikely, in a centralized threat registry.

Each identified threat must then be prioritized and mitigated. Use the DREAD model (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or a simple risk matrix to score threats as High, Medium, or Low. Focus immediate efforts on High-priority items. For each high-risk threat, define a specific mitigation strategy. This could be a code change (adding a reentrancy guard), a configuration update (lowering oracle heartbeat thresholds), or the implementation of a monitoring alert (for anomalous withdrawal volumes). Assign each mitigation to an owner and a timeline.

The final, often overlooked, step is validation and integration into the SDLC. Threat modeling is not complete until mitigations are verified. This involves reviewing pull requests for the implemented fixes, writing or updating relevant tests (e.g., a Foundry invariant test for a newly added guard), and updating documentation. Furthermore, the threat model itself is a living document. It must be revisited and updated for every major protocol upgrade, new feature addition, or when a similar system suffers a novel exploit (e.g., after a cross-chain bridge hack). Integrate a lightweight threat modeling review as a mandatory gate before production deployments.

Threat modeling is a proactive security analysis that identifies potential threats, vulnerabilities, and attack vectors in a system's design. For Web3 projects, this process is critical for securing smart contracts, oracle integrations, and governance mechanisms before they are deployed on-chain. The core methodology involves four key questions: What are we building? What can go wrong? What are we doing about it? Did we do a good job? Frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) provide a structured way to categorize threats specific to decentralized applications.

To run an effective session, assemble a cross-functional team including developers, architects, product managers, and dedicated security engineers. Begin by creating a high-level Data Flow Diagram (DFD) of the application. This visual should map out all trust boundaries—such as transitions between user wallets, frontend clients, smart contracts, and external oracles. Clearly delineating these boundaries is essential, as they are the primary locations where threats manifest. For a DeFi protocol, key components to diagram include the liquidity pool contracts, price feed oracles, admin multisig, and user interaction flows.

With the diagram complete, conduct a structured brainstorming session using the STRIDE framework per element. For each component and data flow, ask: Could an attacker spoof this identity? Tamper with this data? For example, for a price oracle, consider tampering and information disclosure threats. For a governance voting contract, evaluate elevation of privilege and repudiation risks. Document every potential threat in a centralized threat registry, noting the affected component, the STRIDE category, a brief description, and the potential impact severity (e.g., Critical, High, Medium).

For each identified threat, the team must define a mitigation strategy. These are security controls designed to reduce risk to an acceptable level. Mitigations can be technical (e.g., implementing access control with OpenZeppelin's Ownable, adding checks-effects-interactions patterns, using decentralized oracle networks like Chainlink), operational (e.g., implementing a timelock on admin functions), or architectural (e.g., reducing complexity by modularizing contracts). Document the chosen mitigation and the residual risk after its implementation.

The final output is a living threat model report. This document should include the DFD, the complete threat registry with mitigations, and any open issues or assumptions. Tools like the OWASP Threat Modeling Toolkit, draw.io, or even a well-structured spreadsheet are sufficient. This model is not a one-time exercise; it must be revisited and updated after any significant change to the system's design, after a security incident, or as part of a regular quarterly review cycle to ensure ongoing security coverage.

Integrating threat modeling into your development lifecycle is the most critical next step. Formalize it as a mandatory gate before major releases or significant smart contract upgrades. Use frameworks like the OWASP SAMM (Software Assurance Maturity Model) to benchmark and improve your security processes. Automate where possible by integrating tools like Slither or MythX into CI/CD pipelines to catch common vulnerabilities, but remember these tools complement, rather than replace, structured human analysis.

To scale the practice, document your findings in a living Threat Model Registry. This should catalog each model (e.g., VaultDeposit.sol), its associated STRIDE-per-element analysis, mitigated risks, and accepted residual risks. This registry becomes an invaluable onboarding tool for new engineers and auditors. Furthermore, establish a regular cadence for threat model review sessions, especially after any major protocol incident in the broader ecosystem (e.g., a novel oracle manipulation attack) to reassess your assumptions.

Your next actionable steps should include: 1) Running a follow-up session on a cross-chain bridge component or governance mechanism, as these are high-value attack surfaces. 2) Exploring advanced methodologies like FAIR (Factor Analysis of Information Risk) for quantitative risk analysis. 3) Contributing findings (anonymized) to community resources like the Smart Contract Security Registry to advance ecosystem-wide knowledge. The goal is to shift from reactive security patching to proactive, systematic risk management.