Security is all about methodology. But methodology only works if people actually use it, and that means it has to be simple enough to maintain, clear enough for others to navigate, and focused enough to actually highlight risk. Those three properties - simple, clear, focused - are the foundation of any useful threat model.

At Certora, we've developed an approach to threat modeling that we've applied across some of the largest protocols in DeFi. What we've found, over and over, is that teams who invest in threat modeling before writing the first line of code end up with simpler architecture, fewer bugs, and faster audits. And for projects that are further along, it is never too late to start this valuable process. It is always worthwhile to write a threat model document and keep it updated over time.

This article, based on our April 21 workshop, walks through our approach as well as the threat modeling tool used by the Stellar Developer Foundation, and explains how these two complementary tools can lay the groundwork for securing your Soroban smart contracts.

Threat Modeling Matters, Especially as Systems Grow

Developers might be able to keep all the moving parts of a medium-sized project in their heads. But as a protocol matures with more markets, more integrators, more off-chain infrastructure, more multisig signers … it becomes impossible for any single person to hold the full picture. Which oracle providers are integrated, and what are their known issues? What’s our full dependency supply chain? What are our security assumptions about each actor and their keys?

Without a structured way to capture this, gaps in the mental picture are guaranteed to form over time. We had a client recently where threat modeling quickly highlighted a bug that could have been caught much earlier, had they created a threat model early in their development cycle. They may have identified that an oracle they used had a known bug relevant to their specific token. Just having that oracle listed, with a name or contact attached, created a visible point for consideration that didn't exist before.

This is the core promise of threat modeling: maximum security visibility with minimum overhead.

Even if your project is not so large and complex, there are good reasons to still do a process like the ones described below. Even a threat model that is on the small side can be very helpful for you & your auditors, and it might even be a requirement for security-minded stakeholders and funding - more about that later.

The 4 A's Framework

The framework Certora created and uses consistently is built around four “A” categories of aspects of a system. We apply this widely when auditing Web2 projects as well as Web3.

A1 - Assets: What Are We Protecting?

Assets are everything you care about keeping safe, available, or intact. Assets can include:

• Off-chain infrastructure (servers, databases)
• Private keys and signer wallets
• Protocol availability (uptime as a requirement)
• Gas cost predictability
• Reputation and governance integrity

Ask: What do we care about most? What would constitute a catastrophic failure? Don’t expect to think of a comprehensive list in one shot, but start the list and keep thinking. Even a single-line list, "Assets: user liquidity", is ok and more useful than no list at all. Revisit often and grow it as the protocol does.

A2 - Actors: Who and What Has Access?

Every address, contract, or external service that interacts with your system in a meaningful way is an actor. This includes:

• Administrators and governance contracts
• Multisig signers
• Liquidity providers and traders
• Oracle contracts and their operators
• External protocols you integrate with
• Internal protocols you integrate with

The rule of thumb: if an address or service has a distinct control flow within your system, it belongs on this list. If you can't enumerate your actors cleanly, that's a signal your system has grown too complex to reason about safely and may need a design audit.

A3 - Assumptions: What Do We Simply Trust To Be True?

This is often the hardest category, because it requires admitting what you haven't done. Assumptions to document include:

• External services you trust (oracle providers, bridging infrastructure, etc.)
• Parts of the codebase that are assumed safe (e.g., third-party libraries). You should link to your audit history for easy cross-reference of what was audited when, and by whom.
• Hypothetical attack scenarios you've consciously decided are out of scope, and why. Think about compromised oracles and multisigs, DoS, flash mint, and unsupported ERC-20 types.

Documenting assumptions creates an honest map of your risk surface and a record for future auditors. When a new team picks up your protocol, the assumptions section tells them exactly where to start asking interesting questions.

A4 - Attack Vectors: What Are We Afraid Of?

With assets, actors, and assumptions in place, the final step is to be explicit about the specific threats you're considering. This can include classics like:

• Rounding and precision errors
• Front-running and MEV exposure
• Key compromise or phishing
• Oracle manipulation
• Denial-of-service on critical functions
• Access control failures

But, this list isn’t exhaustive. Pose the open-ended question to developers, “when you developed feature / contract X, what attack vectors were considered?” Think creatively to find omissions and add them to the list, mitigating each as you go.

Try to be thorough, but foremost be honest. List any attacks that would hurt any of your assets (A1 list). Let this inform what you test, what you ask auditors to focus on, and what your incident response playbook covers.

The STRIDE Framework For Actions

The 4 A's framework above gives you a system-level picture. The STRIDE approach to threat modeling helps you examine system actions in detail and think critically about each one. The goal is to know “What could go wrong?” 

STRIDE is a tried-and-true methodology where you examine each significant action your contracts can perform (e.g., deposit, withdraw, admin action, governance vote, ...), ideally drawn from a comprehensive data flow diagram. For each action, consider the full data flow from end-to-end and ask these six questions:

• S - Spoofing: Can the action be initiated by someone pretending to be another actor?
• T - Tampering: Can the inputs or outputs of the action be modified maliciously?
• R - Repudiation: Can someone deny having taken the action? Is there sufficient on-chain evidence?
• I - Information Disclosure: Could the action ever leak sensitive data, or could it share more information than strictly necessary?
• D - Denial of Service: Can the action be blocked or made prohibitively expensive, or is there any way for the action to block other actions?
• E - Elevation of Privilege: Can the action allow someone to gain permissions they shouldn't have?

Threat Modeling for Stellar

The Stellar Development Foundation (SDF) has documentation for the STRIDE framework, including a how-to guide, template, and example. These are useful resources for any project, but essential for teams interested in audit support from the SDF. Their Soroban Security Audit Bank program funds audits for qualifying projects and connects them to top audit firms such as Certora, and STRIDE analysis is one of the requirements for SDF Audit Bank readiness.

Putting It Into Practice

Neither the 4 A's nor STRIDE is "better" than the other. They operate at different levels of abstraction. The 4 A's address your overall security posture while STRIDE lets you methodically analyze specific interactions. Together, they help you think through both the big picture and the subtle details to identify more security risks.

In fact, having both a 4 A’s and STRIDE threat models is a strong beacon to every investor, ecosystem partner, and user that you are serious about security. Some partners (e.g. AMMs) will require threat modeling as part of their due diligence process, so building these tools into your project lifecycle can speed up investment and adoption. 

The recommended workflow for either of the threat modeling frameworks above is straightforward:

1. Create the document. Make a living threat model document that maps your 4 A's, STRIDE analysis, or ideally, both. Keep it somewhere visible, not buried behind three layers of wiki navigation and share it with everyone on your project.
2. Fill it in collaboratively. Developers, architects, and security leads should all contribute and discuss. Gaps that surface while raising questions and coming to agreement are often extremely valuable.
3. Update it continuously. Threat models must evolve with your protocol throughout new integrations, new actors, changes to assumptions, etc. At a minimum, reread the document when adding a new feature and consider its effect.
4. Use it in audits. Share the (updated) document with external auditors as soon as possible. A good threat model lets auditors speed run the orientation phase and get to the interesting parts faster. It's one of the highest-leverage things you can do to get more out of an audit engagement.

Start Simple, Certora Can Help

The biggest mistake in threat modeling is not doing it at all because it feels too ominous. You don't need a 10-page document nor a methodology consultant. Start simple and start early with an honest list of what you're protecting, who has access, what you're assuming, and what you're afraid of. Start there and update it as you build. Share it with your auditors. 

We’d love to help you improve your security, whether via formal verification of Soroban smart contracts by Certora Sunbeam, a full-service security analysis, or a free security consultation. If you have questions, talk to a Certora security researcher by signing up for our free Office Hours.

The protocol that performs thoughtful threat modeling will have better audits, fewer catastrophic surprises, and faster incident response than the ones that didn't make the effort.