izar/pytmUm framework Pythonico para modelagem de ameaças
A modelagem de ameaças tradicional muitas vezes chega tarde demais, ou às vezes nem chega. Além disso, criar fluxos de dados e relatórios manualmente pode ser extremamente demorado. O objetivo do pytm é deslocar a modelagem de ameaças para a esquerda, tornando-a mais automatizada e centrada no desenvolvedor.
Com base na sua entrada e definição do design arquitetural, o pytm pode gerar automaticamente os seguintes itens:
O tm.py é um modelo de exemplo. Você pode executá-lo para gerar o relatório e os arquivos de imagem de diagrama que ele referencia:
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
Há também um exemplo de Makefile que encapsula tudo isso em targets que podem ser facilmente compartilhados para múltiplos modelos. Se você tiver o GNU make instalado (disponível por padrão em distribuições Linux, mas não no OSX), basta executar:
make MODEL=the_name_of_your_model_minus_.py
Você deve ter o plantuml.jar no mesmo diretório do seu modelo, ou definir PLANTUML_PATH.
Para evitar instalar todas as dependências, como pandoc ou Java, o script pode ser executado dentro de um contêiner:
# do this only once
export USE_DOCKER=true
make image
# call this after every change in your model
make
Para simplificar o uso do pytm, as dependências do host podem ser completamente isoladas
usando o Devbox. Esta é geralmente uma
alternativa com menor sobrecarga e mais conveniente do que a abordagem com contêiner OCI.
curl -fsSL https://get.jetify.com/devbox | bashdevbox version update~/.config/nix/nix.conf: access-tokens = github.com=YOUR_TOKEN_HEREdevbox.json do projeto: devbox shellpython no seu terminal usando o comando which python. A saída deve ser o seguinte caminho: .devbox/nix/profile/default/bin/pythonsample.png: ./tm.py --dfd | dot -Tpng -o sample.pngexit"Mas eu pensei que já tínhamos acabado com essa coisa de 'escrever código'!" - este é para aqueles de nós que estão gostando demais de conversar com assistentes de IA: confira https://github.com/izar/tm_skills para algumas formas de adicionar o OWASP pytm ao seu assistente de codificação (você ainda precisará ter uma instalação funcional do pytm!).
Todos os argumentos disponíveis:
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
O argumento stale_days tenta determinar quão distantes em dias o script do modelo (que você está escrevendo) está do código que implementa o sistema sendo modelado. Idealmente, eles devem estar bem próximos na maioria dos casos de um sistema em desenvolvimento ativo. Você pode executar isso periodicamente para medir o pulso do seu projeto e a 'frescor' do seu modelo de ameaças.
Atualmente, os elementos disponíveis são: TM, Element, Server, ExternalEntity, Datastore, Actor, Process, Dataflow, Boundary, Lambda, LLM e Agent.
As propriedades disponíveis de um elemento podem ser listadas usando --describe seguido do nome de um elemento: