What is the Trike methodology?
Trike is an open-source threat modeling methodology that approaches security auditing from a risk management and defensive perspective. It derives threats from what a system is supposed to do, and stakeholders decide how much risk is acceptable for each asset.
STRIDE, devised by Microsoft engineers in the late 1990s, gave teams a way to ask what could go wrong: six categories of attack, checked against each part of a system. Trike starts from a different question: Who is meant to use this system, and what are they meant to be able to do with each piece of data?
Take a support agent and a customer record. The agent can read the record but should not be able to delete it. If the system allows a delete, Trike counts that as a threat, whether or not anyone has thought of an attack that would exploit it.
Its developers describe the project's aim as improving the efficiency and effectiveness of existing threat modeling methodologies. The three authors of the version 1 document were Eleanor Saitta, Brenda Larcom, and Michael Eddington. Saitta, who has worked as a security architect at Etsy and now runs a security consultancy, described Trike as a methodology and tool that partially automates the art of security analysis. Larcom, a security researcher, was still developing and presenting the method at Mozilla in 2012.
The authors published a draft of the version 1 methodology document in 2005 and released the methodology under the MIT license. Their view was that much of the work in threat modeling can be automated, and the method generates threats directly from a description of what each actor may do with each asset.
The purposes of Trike
- To make sure the risk a system poses to each asset is acceptable to every stakeholder.
- To communicate what the system is, and the risk it carries, in terms stakeholders can act on.
- To give stakeholders the understanding they need to reduce the risks their own actions create, for themselves and for others.
Benefits of using Trike
- Holistic view: combines business requirements, system implementation, and risk in one framework rather than treating them separately.
- Collaborative: the requirements model gives security, development, and business stakeholders a shared reference for what each actor should and shouldn't be able to do.
- Built-in prioritization: every threat is tied to a specific asset and actor and carries an exposure value, so teams can rank mitigations by the risk stakeholders have agreed to accept.
- Supports risk management: threats are analyzed and assigned a risk value, so the output feeds directly into broader risk decisions.
- Visual: data flow diagrams show how data moves through the system, making the model easier to review for technical and non-technical stakeholders alike.
- Designed for automation: top-level threats can be generated systematically from the requirements model, which makes results more consistent and repeatable. Building the attack trees still relies on the auditor's judgment.
Limitations of Trike
- Complexity: Trike's formal structure takes more expertise to apply than lighter methodologies, which can be a hurdle for teams new to threat modeling.
- Resource intensive: building a complete requirements model and implementation model takes time, and teams may need training to use the method well.
- Hard to scale: the method assumes the team understands the whole system, which gets difficult on large, distributed architectures.
- Alignment challenges: stakeholders have to agree on acceptable risk for each asset, which is harder in organizations with competing priorities.
- Limited documentation: version 1 is the only fully documented release. Later versions were only partially documented.
How Trike works
Trike builds a threat model on top of two other models: a requirements model, which describes what the system should do, and an implementation model, which describes how it actually works.
1. Requirements model
The team lists the system's actors, assets, and intended actions, along with the rules that govern them. These are arranged in an actor-asset-action matrix: assets run along one axis, actors along the other, and each cell covers the four basic actions of creating, reading, updating, and deleting (CRUD). For each action, the team records whether it is allowed, disallowed, or allowed only under certain rules.
Because this model only needs to know what the system is meant to do, teams can start it as soon as they begin defining the application, before any architecture exists.
2. Implementation model
Next, the team builds a data flow diagram (DFD) of the system, which shows the entities in the implementation and the paths along which they exchange information. The team then maps the system's actions onto that implementation to show every way an asset can be affected from inside the system.
3. Threat model
Trike then derives threats by comparing the implementation against the requirements. In version 1, threats fall into two categories: denial of service, where an actor can't perform an action they should be able to, and elevation of privilege, where an actor can perform an action they shouldn't. Each threat becomes the root of an attack tree that maps out how it could be carried out.
4. Risk model
Finally, the team assigns risk values. Each asset gets a business value in dollars. Actions are rated from one to five by how undesirable they are, and actors from one to five by how much they are trusted.
Multiplying an asset's value by the action's risk gives the exposure of each threat, which can be weighed against the level of risk stakeholders have agreed is acceptable. Weaknesses are scored separately for how reproducible and exploitable they are.
Trike risk model example: elevation of privilege on a high-value asset
The numbers below are invented for illustration. The v1 document has no worked example, so the scales and formulas come from it, but the values have been created by us to explain how Trike risk calculations can work.
- Exposure = asset value × action risk (1 to 5, rated separately for "authorized action blocked" and "unauthorized action succeeds").
- Weakness score = reproducibility × exploitability × actor risk (each 1 to 5, so the maximum is 125). Actor risk is the value of the least trusted actor who could use the weakness: 1 is highly trusted, 5 is anonymous.
- Threat risk = exposure × the largest applicable weakness score.
Example:
Threat: a support agent deletes customer records, which no rule allows.
| Step | Input | Value |
|---|---|---|
| Asset value | Customer database | $1,000,000 |
| Action risk | Unauthorized delete succeeds | 5 |
| Exposure | $1,000,000 × 5 | 5,000,000 |
| Weakness | Reproducibility | Exploitability | Actor risk | Score |
|---|---|---|---|---|
| Missing permission check on the delete function | 4 | 3 | 2 (support agent, trusted) | 24 |
| Unprotected admin endpoint | 3 | 2 | 5 (anonymous) | 30 |
Threat risk: 5,000,000 × 30 (largest weakness score) = 150,000,000
Trike versions
- Version 1: documented in a draft methodology document published in July 2005. Generates threats from the actor-asset-action matrix and builds an attack tree for each threat. Attack tree generation is not fully automated and relies on auditor judgment at certain points.
- Version 1.5: partially documented in the help spreadsheet that ships with its tool. A bridge between versions 1 and 2 that added security objectives and HAZOP analysis and dropped threat trees.
- Version 2: a superset of version 1.5 that adds semi-automatic threat generation at the architectural level and attack chaining. It has been previewed in conference talks but not fully documented.
Should I consider other threat modeling methodologies?
Trike is one of several established threat modeling methodologies, alongside frameworks like STRIDE, PASTA, OCTAVE, and VAST. To compare approaches, see Threat Modeling Methodologies.
Where threat modeling automation helps
Trike was designed with automation in mind, but its manual steps are still where teams get stuck: building and maintaining the matrix, redrawing data flow diagrams, and rescoring risk every time the architecture changes.
Deciding what your critical assets are and how much risk the business can accept stays a human call. Keeping the model current doesn't have to be manual. In ThreatModeler Nexus, you mark which components hold something worth protecting and set how much risk the system carries for the business, and threats are scored on likelihood and impact against those settings.
The platform's agentic features then analyze findings based on your specific architecture and components. It flags threats that look non-applicable with evidence and a confidence rating, runs attack path analysis from entry point to impact, and suggests a remediation sequence.
Frequently asked questions
What is the difference between Trike and STRIDE?
STRIDE starts from six categories of attack and asks which ones apply to each part of a system. Trike starts from what each actor should be allowed to do with each asset, and treats any deviation from that as a threat. STRIDE is usually quicker to apply, while Trike takes more upfront work but ties every threat to a specific asset, actor, and acceptable risk level.
What models does Trike use?
Trike uses a requirements model (an actor-asset-action matrix), an implementation model (a data flow diagram), and a threat model derived by comparing the two. Risk values are then assigned to assets, actors, and actions.
Is Trike open source?
Yes. The methodology was released under the MIT license, so anyone can use and adapt it, and the project's methodology papers, tools, and talks were published openly.
Can Trike be combined with other methodologies?
Yes. For example, a team could use Trike's requirements model to define acceptable behavior and risk for each asset, then use a threat enumeration approach such as STRIDE to brainstorm threats for each component.
Is Trike suitable for large systems?
It can be hard to apply to large, distributed systems, because it assumes the team understands the whole system. Scoping the analysis to a single application or a critical data flow keeps it manageable.
Trike is an open-source, risk-based threat modeling methodology built on a requirements model and a data flow diagram. See how it works, plus pros and cons.
