Building Threat Models in Draw.io: How XML Libraries Turn Free Diagrams into Security Tools

Hook

Most security teams spend thousands on threat modeling tools, but one developer proved you can do enterprise-grade threat modeling with nothing but free diagramming software and cleverly designed XML files.

Context

Threat modeling should be a standard practice in every development team's security toolkit, but adoption remains surprisingly low. The barriers are real: Microsoft Threat Modeling Tool only runs on Windows, OWASP Threat Dragon is still maturing, and commercial platforms like IriusRisk cost thousands per user annually. Meanwhile, most engineering teams already use Draw.io (diagrams.net) for architecture diagrams, flowcharts, and documentation. The cognitive overhead of learning yet another specialized tool—especially one that doesn't integrate with existing workflows—keeps threat modeling in the "we should do this someday" category.

Michael Henriksen identified this gap and took a different approach: instead of building another standalone application, he created reusable shape libraries that extend Draw.io's existing capabilities. The michenriksen/drawio-threatmodeling repository contains XML library files that provide pre-built visual vocabularies for Data Flow Diagrams (DFDs) and Attack Trees—two fundamental threat modeling methodologies. By leveraging a tool developers already know and trust, the barrier to entry drops dramatically. You get version-controllable, team-shareable threat models without installing specialized software, learning proprietary formats, or fighting with licensing servers.

Technical Insight

At its core, this project is a collection of XML files that define custom shape libraries for Draw.io. Each library follows Draw.io's native XML schema for shape definitions, which means they integrate seamlessly without requiring plugins or extensions. Let's examine how this works by looking at the structure of a typical shape definition.

Draw.io libraries use an XML format where each <mxCell> element defines a shape with its geometry, styling, and metadata. Here's a simplified example of how a "Process" shape for a DFD might be structured:

<mxlibrary>[{
  "xml": "<mxGraphModel><root><mxCell id='0'/><mxCell id='1' parent='0'/><mxCell id='2' value='Process Name' style='rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;' vertex='1' parent='1'><mxGeometry width='120' height='60' as='geometry'/></mxCell></root></mxGraphModel>",
  "w": 120,
  "h": 60,
  "title": "Process",
  "aspect": "fixed"
}]</mxlibrary>

This JSON-wrapped XML structure tells Draw.io exactly how to render the shape, including dimensions, colors, and default labels. The style attribute uses Draw.io's styling language to define appearance—rounded corners for processes, different colors for trust boundaries, specific line styles for data flows. By standardizing these visual elements, the library ensures that everyone on your team creates consistent, recognizable threat models.

The repository includes multiple libraries covering different aspects of threat modeling. The DFD library provides shapes for external entities (users, external systems), processes (application components), data stores (databases, file systems), and data flows (connections showing data movement). Each shape follows established DFD conventions—external entities are rectangles, processes are circles or rounded rectangles, data stores are open-ended rectangles. Trust boundaries appear as dashed lines that you can draw around groups of components to indicate security perimeters.

The Attack Tree library takes a different approach, providing shapes for tree-structured analysis of attack vectors. Root nodes represent attacker goals, intermediate nodes show sub-goals or steps, and leaf nodes represent atomic attack actions. By combining AND/OR logic gates, you can model complex attack scenarios and identify which combinations of vulnerabilities an attacker might chain together.

What makes this architecture particularly elegant is its simplicity. There's no runtime code, no JavaScript plugins, no security boundary violations. You import the XML library into Draw.io once, and the shapes become available in your shape palette permanently. They're stored in Draw.io's local storage, synchronized across devices if you use the web version, and can be re-imported anytime. The diagrams you create are standard Draw.io files—.drawio XML documents that can be opened, edited, and version-controlled like any other source code artifact.

For teams wanting to customize the libraries, the XML format is straightforward to modify. You might want to add your company's color scheme, include additional shape types for your specific tech stack, or create templates for common architecture patterns. Since everything is defined declaratively in XML, you can fork the repository, edit the library files, and distribute your customized version to your team through Git. Here's how you might extend the library with a custom "API Gateway" shape:

{
  "xml": "<mxGraphModel><root><mxCell id='0'/><mxCell id='1' parent='0'/><mxCell id='2' value='API Gateway' style='shape=hexagon;perimeter=hexagonPerimeter2;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;' vertex='1' parent='1'><mxGeometry width='140' height='70' as='geometry'/></mxCell></root></mxGraphModel>",
  "w": 140,
  "h": 70,
  "title": "API Gateway",
  "aspect": "fixed"
}

This extensibility means the libraries can grow with your organization's needs without waiting for upstream contributions or vendor feature requests. You control the visual language of your threat models completely.

Gotcha

The biggest limitation of this approach is also its core design principle: it's purely visual. Draw.io with these libraries gives you a canvas and standardized shapes, but it won't automatically enumerate threats based on your diagram. Dedicated threat modeling tools apply STRIDE methodology automatically—when you draw a data flow crossing a trust boundary, they suggest authentication, authorization, and encryption threats. With Draw.io, you must apply that analysis manually. You're responsible for walking through each element, considering applicable threat categories, and documenting mitigations in text annotations. For experienced security practitioners, this manual process might actually be preferable—it forces thoughtful analysis rather than checkbox compliance. For teams new to threat modeling, the lack of guidance can be overwhelming.

The libraries also can't enforce semantic correctness. Nothing prevents you from creating a DFD with data flows that violate standard conventions, or an Attack Tree with circular logic. Draw.io doesn't understand that a process should have at least one input and one output, or that trust boundaries should completely enclose components. Inconsistent diagram quality becomes a real risk, especially as teams scale. Code review for threat models becomes critical—you need someone with threat modeling expertise to validate that diagrams are both visually correct and semantically meaningful. There's also no integration with ticketing systems, no way to automatically generate security requirements or test cases from your diagrams, and no collaboration features beyond what Draw.io provides natively. If you need threat models to feed directly into Jira, generate compliance reports, or integrate with your CI/CD pipeline, you'll be building that integration layer yourself.

Verdict

Use if: Your team already uses Draw.io for technical diagrams and you want to introduce threat modeling without adding another tool to your stack. This is ideal for startups and small-to-medium engineering teams who need version-controlled, collaborative threat modeling that lives alongside architecture documentation in Git. The zero-cost, zero-installation approach removes bureaucratic friction and lets you start threat modeling today. It's also perfect if you value flexibility and customization over automated guidance—experienced security engineers will appreciate the clean canvas approach. Skip if: You need automated threat enumeration, STRIDE analysis, or compliance reporting. Teams new to threat modeling will struggle without the guardrails that dedicated tools provide. Also skip if you require integration with security toolchains, automated report generation, or enterprise features like SSO and audit logs. In those cases, invest in Microsoft Threat Modeling Tool for Windows environments, OWASP Threat Dragon for cross-platform open-source needs, or commercial platforms like IriusRisk if budget allows and you need the full enterprise feature set.