Yes. pytm is an open source Python framework that lets you describe a system as code, then generates a data flow diagram, a sequence diagram and a report of matching threats. It suits teams that want threat models in version control, reviewed in pull requests like any other file.
What pytm does
According to the project page, pytm aims to move threat modeling earlier in development and make it more automated and developer centric. You write a Python script that declares the model's parts, then run it.
Core building blocks include a model object, servers, datastores, actors, lambdas, boundaries, data flows and the data that moves. You connect elements with a data flow that names a source, a sink and a label, and set attributes such as protocol, destination port, the boundary an element sits in, and its controls.
What you get out
- A data flow diagram, written as Graphviz output and rendered with the dot tool
- A sequence diagram, written as PlantUML output
- A report, filled from a template, which can be converted with pandoc
- A JSON dump and a list of threats
- A staleness check that shows how far the model has drifted from the code it describes
Threat rules come from a database of more than 100 entries, and you can supply your own file. The project warns that the rule conditions are evaluated with eval, so protect that file like code.
What you need installed
The page lists Linux or macOS, Python 3.11 or later and Graphviz. Sequence diagrams need Java and a PlantUML jar, and HTML reports need pandoc. Docker and Devbox options exist to avoid manual installs. The page does not state the license type on the content I could read, so check the repository before adopting it.
Code or whiteboard: a quick comparison
| Question | Model as code | Whiteboard or drawing tool |
|---|---|---|
| Reviewed in pull requests | Yes | Only if exported |
| Easy for non-developers | Harder | Easier |
| Shows drift from code | Has a staleness check | Manual |
| Setup effort | Higher | Lower |
| Good for | Teams that live in the repo | Mixed groups, first sessions |
A sensible path is to hold the first session at a whiteboard, then encode the agreed diagram as code if the team wants it kept current.
Tips for keeping a code model honest
- Keep the model file in the same repository as the system it describes.
- Run the staleness check in CI so a drifting model is noticed.
- Treat generated threats as prompts for discussion, not as findings.
- Review model changes in the same pull request as design changes.
Quick check
Does pytm replace a threat modeling session?
No. It generates candidate threats from the structure you describe. The conversation about what matters and what to do remains a human job.
Is a model as code better than a drawing?
Neither is better in general. Code is easier to version and review. Drawings are easier for mixed groups. Pick what your team will actually keep up to date.
A note on tooling
pytm models the design. Safeguard checks what you build from it, with SBOM and dependency scanning and policy gates that can run on pull requests. A free scan takes a repository link.
Sources
Last reviewed: 19 October 2026.
