Find what can go wrong, while you draw

A threat model is a list of the ways your system could be attacked or fail, with what you will do about each one. In Modudraft it sits on the Architecture tab, next to the diagram it describes, so it changes when the diagram changes. It is part of the same file, with the same version history and share link.

Step by step Build a threat model

What it is

You mark which parts of the system are trusted, say what kind of data each arrow and data store carries, and Modudraft suggests threats from that. Each threat is about one thing: a component, an arrow, a boundary or the whole diagram. Every threat has a STRIDE category, a severity, a status, and room for a description, a mitigation and an owner.

• STRIDE sorts threats into six kinds: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege.
• Severity is low, medium, high or critical.
• Status is suggested, open, mitigated, accepted or not applicable.
• A file has one threat model, on the Architecture tab. The other tabs cannot hold threats. With more than one Architecture tab, the first one that gets a threat holds the model.
• A title can be up to 200 characters, a description or mitigation up to 2000 and an owner up to 100.
• Files that have no threat model open exactly as before.

To see it on the canvas, press Security view in the canvas controls. It shows trust zones, how each arrow is protected and a badge with the open threats on each item. The Threats button in the toolbar opens the list. People with view access can see the Security view and the list, but they cannot change anything.

Trust zones

A trust zone says how far you trust what runs inside it. Set one on a boundary: select the boundary and pick a Trust zone in its Security card.

• Internet: anything on the public internet, including your users' browsers.
• DMZ: the edge you expose, such as a gateway or load balancer.
• Internal: your own services on a private network.
• Restricted: the most protected part, such as the database that holds customer data.
• Third-party: services run by someone else.

An item's zone is worked out like this:

• A boundary with a zone has that zone.
• Otherwise an item takes the zone of the smallest zoned boundary that contains it on its own level, or of the component it is inside.
• An External or Client component with no zone is treated as Internet, and anything else as Internal.

Moving an item into or out of a boundary changes its zone. An arrow that goes from one zone to another crosses a trust boundary, and that is where most of the suggested threats come from.

Data classes

Arrows and data stores can say what kind of data they carry or hold: public, internal, PII, credentials or payment. PII, credentials and payment count as sensitive. Select an arrow or a store and use the Security card in the side panel.

• An arrow also has Encrypted: yes, no or unknown. When you leave it unset, it comes from the arrow's protocol (HTTPS is encrypted, HTTP is not, and names such as REST or gRPC are unknown).
• A data store has Encrypted at rest. Data stores are components of these types: database, cache, queue, storage, search, warehouse and secrets.

You do not need to fill in everything. An unset value is treated as unknown, and the rules will point out where unknown matters.

Suggested threats

Press Suggest threats in the Threats panel. Modudraft reads the diagram and adds the new suggestions with the status suggested, each with a description and a mitigation. The rules are deterministic: the same diagram always gives the same suggestions. They work in two layers.

• Graph rules read the shape of the diagram: an unencrypted arrow that crosses a zone, direct access to a restricted store, sensitive data sent to a third party, a sensitive store that is not encrypted at rest, an entry point that takes traffic from the internet, and a system with no logging or observability component.
• Archetype rules are the usual weaknesses of each kind of component: a gateway with no rate limit, a database with no backups, a storage bucket open to the public, a client that keeps tokens where they can be stolen, and so on. Where it matters, a rule only fires when the diagram shows the weakness, for example when a gateway has no rate limit set.

A suggestion that applies to an item taking traffic from the internet, or an item that touches sensitive data, is raised one severity level.

There are no rules for individual tools, and Modudraft does not track CVEs or vulnerabilities in the versions you run. The rules know that something is a gateway or a database, not which product it is. Weaknesses specific to a product are added by an agent (see With an agent) or by you.

Work the list

• Accept all suggested turns every suggestion into an open threat (it asks first). You can also set each one's status on its own.
• Click a threat in the list to select and zoom to the thing it is about. Filter by status, severity or STRIDE category.
• Select any component, arrow or boundary and the Security card in the side panel lists its threats. Add your own there, and edit the title, severity, status, mitigation and owner.
• Running Suggest threats again never adds the same threat twice, never changes a threat you edited, and never brings back one you marked not applicable. Mark a suggestion not applicable instead of deleting it. If you delete an arrow and draw it again, it counts as a new arrow, so its threats are suggested again.
• If you delete something that has threats, the threats stay, marked Target removed.

With an agent (MCP)

Agents can build and review a threat model through the security toolset of the MCP server. Because the rules do not know your tools, the agent does that part:

• get_security_view returns the zones, data classes and threats, and for each component its tool and archetype, such as Kong as a gateway or S3 as storage.
• set_trust_zone and set_data_class fill in the zones and data classes the diagram is missing.
• suggest_threats runs the same rules as the web app.
• add_threat adds threats that are specific to a tool, marked as coming from the agent: for example that a Kong route has no rate-limiting plugin, or that an S3 account does not have Block Public Access turned on.
• update_threat fills in mitigations, owners and statuses, and delete_threat removes a threat.
• export_threat_model gives the Markdown report.

The threat_model prompt does all of this in one go for a diagram. Threat edits are sent as small changes, so they do not overwrite what someone is editing in the web app at the same time. The agent's threats are marked agent in the list and the report, next to the ones from the rules and the ones you add.

The report

The report is a page you can print or share. Open it with Open report in the Threats panel, at /d/<id>/threat-report, or at /s/<token>/threat-report for a share link. Anyone who can view the diagram can open its report. It has:

• The system diagram, with its trust zones.
• The components in each trust zone.
• Data flows grouped by class, with their encryption, and the data stores.
• A table of threats: number, title with its source and description, STRIDE category, target, severity, status, mitigation and owner.
• Counts by status and by severity.
• The method, who owns the threats, the date it was generated and the diagram version.

• PDF: press Print / Save as PDF and choose Save as PDF. The page is set up for A4 and always prints dark text on white.
• Markdown: use Threat model (.md) in the toolbar's Export menu, or export_threat_model from an agent. It has the same content as the page. Text you wrote in threats is escaped, so it is safe to paste into other tools.

See a finished one: the example report.

Try it

The Threat model example on the home page is a live web shop with zones, data classes and a mix of open, mitigated and accepted threats. Click Invoice bucket or an arrow to see what is on it. Then read its report. Or open it in the demo, no sign-up needed.