PS Product SecurityKnowledge Base

Threat Modeling

Threat Modeling

Section focus: Threat Modeling.
Best use: start with the section map below, then move into the deeper pages that match your role or stack.
Design note: this index was refreshed to act as a cleaner GitBook landing page instead of a plain directory listing.

Start with these pages

Page Why open it first
🧭 Threat Modeling Methods and Workflows High-value page inside Threat Modeling.
🏢 Multi-Tenant and Microservice Threat Modeling High-value page inside Threat Modeling.
📝 Architecture Review Question Bank and Decision Records High-value page inside Threat Modeling.
☸️ Threat Modeling Process — Kubernetes Example High-value page inside Threat Modeling.
🧱 Security Requirements, Trust Boundaries, Data Flows, and Architectural Trade-offs Fast reference page for the core secure-design concepts reviewers keep re-explaining.
🧭 STRIDE, DREAD, and PASTA — Practical Comparison Practical comparison of classic threat-modeling methods, where they fit, and how to translate findings between them.

Intro: Threat modeling is the planning layer that explains why the controls in this archive exist. The useful version is not a one-time workshop. It is a repeatable review habit that helps teams pick the right controls, not just more controls.

What this page includes

  • practical threat-modeling workflows for product teams
  • multi-tenant and microservice review patterns
  • architecture review question banks and decision records
  • cross-links into API, cloud, and detection work

Working assumptions

  • the model should be fast enough to use before design freeze
  • the output should change backlog, defaults, or gates, otherwise the exercise was too abstract

Section map

Page Why it belongs here
Threat Modeling Methods and Workflows Turns threat modeling into a repeatable operating rhythm instead of a ceremonial workshop.
Multi-Tenant and Microservice Threat Modeling Focuses on the trust boundaries that repeatedly matter in SaaS products.
Architecture Review Question Bank and Decision Records Gives reviewers concrete questions and a durable way to record trade-offs.
Security Requirements, Trust Boundaries, Data Flows, and Architectural Trade-offs Gives concise definitions and a review table for the concepts that anchor most threat-model outputs.
STRIDE, DREAD, and PASTA — Practical Comparison Explains where each model helps, where it misleads, and how teams can map outputs between methods.

Core principle

A threat model is useful when it changes one of four things:

  1. a design decision;
  2. a default platform control;
  3. a release or review gate; or
  4. a monitoring and response requirement.

If none of those moved, the exercise probably produced vocabulary rather than security.

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.