owasp/pytmA Pythonic framework for threat modeling
Traditional threat modeling too often comes late to the party, or sometimes not at all. In addition, creating manual data flows and reports can be extremely time-consuming. The goal of pytm is to shift threat modeling to the left, making threat modeling more automated and developer-centric.
Based on your input and definition of the architectural design, pytm can automatically generate the following items:
The tm.py is an example model. You can run it to generate the report and diagram image files that it references:
mkdir -p tm
./tm.py --report docs/basic_template.md | pandoc -f markdown -t html > tm/report.html
./tm.py --dfd | dot -Tpng -o tm/dfd.png
./tm.py --seq | java -Djava.awt.headless=true -jar $PLANTUML_PATH -tpng -pipe > tm/seq.png
There's also an example Makefile that wraps all these into targets that can be easily shared for multiple models. If you have GNU make installed (available by default on Linux distros but not on OSX), simply run:
make MODEL=the_name_of_your_model_minus_.py
You should either have plantuml.jar on the same directory as your model, or set PLANTUML_PATH.
To avoid installing all the dependencies, like pandoc or Java, the script can be run inside a container:
# do this only once
export USE_DOCKER=true
make image
# call this after every change in your model
make
To simplify the usage of pytm host dependencies can be completely isolated
using Devbox. This is usually a
lower overhead and more convenient alternative to the OCI container approach.
curl -fsSL https://get.jetify.com/devbox | bashdevbox version update~/.config/nix/nix.conf file file: access-tokens = github.com=YOUR_TOKEN_HEREdevbox.json file: devbox shellpython in your terminal by using the which python command. The output should be the following path: .devbox/nix/profile/default/bin/pythonsample.png: ./tm.py --dfd | dot -Tpng -o sample.pngexit"But I thought we were done with this 'writing code' thing!" - this one is for those of us who are enjoying too much talking to AI assistants: check out https://github.com/izar/tm_skills for some ways to add OWASP pytm to your coding assistant (you'll still need to have a working install of pytm!).
All available arguments:
usage: tm.py [-h] [--debug] [--dfd] [--report REPORT] [--exclude EXCLUDE]
[--seq] [--list] [--colormap] [--describe DESCRIBE]
[--list-elements] [--json JSON] [--levels LEVELS [LEVELS ...]]
[--stale_days STALE_DAYS]
options:
-h, --help show this help message and exit
--debug print debug messages
--dfd output DFD
--report REPORT output report using the named template file (sample
template file is under docs/basic_template.md)
--exclude EXCLUDE specify threat IDs to be ignored
--seq output sequential diagram
--list list all available threats
--colormap color the risk in the diagram
--describe DESCRIBE describe the properties available for a given element
--list-elements list all elements which can be part of a threat model
--json JSON output a JSON file
--levels LEVELS [LEVELS ...]
Select levels to be drawn in the threat model (int
separated by comma).
--stale_days STALE_DAYS
checks if the delta between the TM script and the code
described by it is bigger than the specified value in
days
The stale_days argument tries to determine how far apart in days the model script (which you are writing) is from the code that implements the system being modeled. Ideally, they should be pretty close in most cases of an actively developed system. You can run this periodically to measure the pulse of your project and the 'freshness' of your threat model.
Currently available elements are: TM, Element, Server, ExternalEntity, Datastore, Actor, Process, Dataflow, Boundary, Lambda, LLM and Agent.
The available properties of an element can be listed by using --describe followed by the name of an element: