Model your threats
In a dedicated studio, you build your DFD and see the STRIDE threats for each element.
You can compare the diagram with the latest scan.
If signs of a threat reappear, you know what to review.
For architects
Model before the code.
Verify with the code.
A flow crosses a trust boundary: which threats need review?
Model components and exchanges, then compare STRIDE threats with scan findings.
You have a scenario to discuss and specific code evidence to check.
Request a demo
A 30-minute demo on a project close to yours.
From design to proof
The architecture model, tied to the code.
Four views of one model: containers, threats, components and attack techniques.
Demo screenshots. Results illustrate this project, not every project.
Tamis interface · scanned WebGoat project
Under the hood
- Generation
- Generate STRIDE threats from your model without AI. For the DFD, start with a description processed by local AI or rules.
- Detection
- Prepare your detections with a MITRE ATT&CK Navigator export and Sigma rules to validate in your environment.
- AI inventory
- Find the AI components identified at each scan in an AI-BOM you can export as CycloneDX.
- Drift
- Compare your diagram with the latest scan on demand to review differences.
- Deployment
- SaaS in the EU (OVHcloud or Scaleway) or self-hosted, air-gapped included
In Tamis
Make risks visible as you design.
Connect architecture to findings
C4 mapping connects your components, flows and trust boundaries to project findings.
You can compare and merge a draft of your future architecture without overwriting the current state.
Find where a control could help
The DFD graph identifies a point between the exposed surface and sensitive data.
A control there could protect several access paths.
Proximity also affects priority: a threat one hop from a payment database ranks ahead of the same flaw five hops away.
Find your APIs
You see API endpoints found in code, specifications or traffic.
Tamis flags schema drift.
It also flags endpoints present in code but never observed in traffic, or the reverse.
Prepare your EBIOS RM workshops
You organize business assets, risk sources and scenarios, through to treatment.
Operational scenarios are prefilled from attack chains already detected.
Evidence is cited to help you review them.
Share abuse scenarios
The model provides scenarios describing how a malicious user could act.
You can pass them to development and testing teams.
On the same evidence
What moves between roles.
You receive
- Confirmed code findings, so you can see which threats from the model have materialized.
- Pentest attack chains linked to threats in your DFD.
- The CISO's risk decisions to guide your next design choices.
You pass on
- Threats to include in the project's risk register.
- Abuse scenarios to scope the pentester's engagement.
- The architecture context AppSec needs to prioritize.
Good to know Your threat model describes what the team designed.
To know what the code actually does, you need findings and tests.
On the blog
Go further.
The mechanics explained simply, then in depth. All articles
