
إطار عمل بايثوني لنمذجة التهديدات
نمذجة التهديدات التقليدية غالبًا ما تأتي متأخرة إلى الحفلة، أو في بعض الأحيان لا تأتي إطلاقًا. بالإضافة إلى ذلك، فإن إنشاء تدفقات البيانات والتقارير يدويًا يمكن أن يستغرق وقتًا طويلاً للغاية. الهدف من pytm هو تحويل نمذجة التهديدات إلى اليسار، مما يجعل نمذجة التهديدات أكثر آلية وتركز على المطور.
بناءً على مدخلاتك وتعريف التصميم المعماري، يمكن لـ pytm توليد العناصر التالية تلقائيًا:
إن tm.py هو نموذج مثال. يمكنك تشغيله لتوليد ملفات التقرير وصور المخططات التي يشير إليها:```
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
هناك أيضًا مثال `Makefile` يغلّف كل هذه في أهداف يمكن مشاركتها بسهولة عبر نماذج متعددة. إذا كان لديك [GNU make](https://www.gnu.org/software/make/) مثبتًا (متوفر افتراضيًا على توزيعات لينكس ولكن ليس على OSX)، فما عليك سوى تشغيل:```
make MODEL=the_name_of_your_model_minus_.py
يجب أن يكون لديك إما plantuml.jar في نفس دليل النموذج الخاص بك، أو تعيين PLANTUML_PATH.
لتجنب تثبيت جميع التبعيات، مثل pandoc أو Java، يمكن تشغيل السكربت داخل حاوية:```
export USE_DOCKER=true make image
make
### البدء - متغير Devbox
لتبسيط استخدام `pytm`، يمكن عزل تبعيات المضيف بالكامل باستخدام [`Devbox`](https://github.com/jetify-com/devbox). وعادةً ما يكون هذا بديلاً أقل تكلفة وأكثر ملاءمة من نهج حاويات OCI.
- ثبّت Devbox على Linux/MacOS: `curl -fsSL https://get.jetify.com/devbox | bash`
- ثبّت Devbox على [Windows/WSL](https://www.jetify.com/docs/devbox/installing-devbox/index#installing-wsl2)
- حدّث إلى أحدث إصدار من devbox: `devbox version update`
- عيّن رمز وصول GitHub الخاص بك في ملف `~/.config/nix/nix.conf`: `access-tokens = github.com=YOUR_TOKEN_HERE`
- أنشئ بيئة shell معزولة وجديدة تتضمن جميع الأدوات والحزم المحددة في ملف `devbox.json` الخاص بالمشروع: `devbox shell`
- اعرض المسار الكامل لملف Python التنفيذي الذي سيُستخدم عند كتابة `python` في الطرفية باستخدام الأمر which python. يجب أن يكون الناتج هو المسار التالي: `.devbox/nix/profile/default/bin/python`
- اختبر بتشغيل الأمر التالي، والذي يجب أن يولّد مخطط تدفق البيانات (DFD) كملف PNG باسم `sample.png`: `./tm.py --dfd | dot -Tpng -o sample.png`
- اخرج من بيئة shell الخاصة بـ Devbox: `exit`
## الاستخدام
جميع الوسائط المتاحة:```text
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/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
وسيطة stale_days تحاول تحديد مدى البعد بالأيام بين السكربت النموذجي (الذي تكتبه) وبين الكود الذي ينفّذ النظام الذي يتم نمذجته. ومن الناحية المثالية، ينبغي أن تكونا قريبتين جدًا في معظم حالات النظام الذي يتم تطويره بنشاط. يمكنك تشغيل هذا بشكل دوري لقياس نبض مشروعك و"حداثة" نموذج التهديد الخاص بك.
العناصر المتاحة حاليًا هي: TM وElement وServer وExternalEntity وDatastore وActor وProcess وSetOfProcesses وDataflow وBoundary وLambda وLLM وAgent.