OWASP pytm can emit DFDs, reports, and JSON from code, making STRIDE checks repeatable in CI/CD. Learn the AI-assisted pipeline setup. Full breakdown.
Why STRIDE Belongs in the Pipeline
Threat modeling often happens once, on a whiteboard, then drifts out of date as services and data flows change. STRIDE gives you a fixed checklist—spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege—but the value only holds if the model stays current. Encoding the model in code turns that checklist into something a pipeline can run on every meaningful change, the same way unit tests guard behavior.
When the model lives next to the application definition, reviewers can see which trust boundaries, data stores, and actors were assumed. CI becomes the place that fails a build when a new element appears without mitigations, or when an existing flow no longer matches the documented design. The goal is not a longer security report; it is a repeatable signal that security assumptions still match the system you are shipping.
What OWASP pytm Gives You as Code
OWASP pytm lets you describe processes, data stores, actors, and data flows in Python and then generate artifacts from that description. From a single model you can emit data-flow diagrams, human-readable reports, and machine-readable JSON. The DFD is for review and design conversations. The report is for auditors and security partners. The JSON is for automation—parsing findings, gating merges, or feeding later tooling.
Because the model is code, it can sit in the same repository as the service, follow the same review process, and version with the same commits. That closes the usual gap where architecture diagrams live in a slide deck while the real topology evolves in pull requests. STRIDE rules applied to the model become checks you can re-run whenever the model or the pipeline definition changes.
Building an AI-Assisted CI/CD Setup
A practical pipeline keeps humans in the loop for judgment and uses automation—and, where it helps, AI—for draft work and consistency. A solid flow looks like this:
- Maintain a pytm model that names boundaries, trust levels, and critical data paths for the service under change.
- On pull request, run the model to regenerate the DFD, report, and JSON so reviewers see fresh artifacts, not stale exports.
- Parse the JSON (or report sections) for missing mitigations, open threats, or elements that lack owners, and fail the job when those conditions are met.
- Use an AI assistant to propose new elements and STRIDE questions when the diff touches auth, storage, or external integrations—then require an engineer to accept or reject those edits before merge.
- Publish the generated DFD and report as pipeline artifacts so design and security can review without re-running the model locally.
AI is most useful early: sketching flows from a service description, suggesting STRIDE questions for a new store, or summarizing which threats still lack a control. It should not silently invent mitigations or mark threats resolved. The model file remains the source of truth; AI only accelerates drafting and review comments that humans still own.
Keeping the Model Honest Over Time
Automation fails when the model is ornamental. Treat model updates as part of the definition of done for features that add actors, stores, or cross-boundary traffic. If a change never touches the model, either the change is purely internal or the model is incomplete—both cases deserve a deliberate choice, not silence. Prefer small, service-scoped models over one giant enterprise diagram that nobody wants to edit.
Start with the highest-risk paths: authentication, secrets, payment or personal data, and any hop that leaves your trust boundary. Wire pytm generation into CI so DFD, report, and JSON always match the committed model. Use those outputs to drive review discussion, not as a substitute for it. Over time, the combination of code-defined STRIDE checks, pipeline-enforced artifacts, and AI-assisted drafting makes threat modeling something you can maintain at the same cadence as the product—without pretending a single workshop covers every release.