What is Threat Modeling?

How Threat Modeling Works

The most widely used threat modeling framework is STRIDE, developed by Microsoft. STRIDE identifies six threat categories: Spoofing identity — attackers claiming to be someone they are not; Tampering with data — unauthorized modification of data; Repudiation — denying actions that were performed; Information Disclosure — exposing data to unauthorized parties; Denial of Service — degrading or denying service availability; Elevation of Privilege — gaining capabilities beyond what is authorized. STRIDE systematically applies these threat categories to every component of the system architecture being modeled.

The PASTA methodology — Process for Attack Simulation and Threat Analysis — is a risk-centric approach that incorporates attacker perspective and business impact assessment. MITRE ATT&CK-based threat modeling applies specific attacker techniques documented in the ATT&CK matrix to identify the most relevant threats based on real-world adversary behavior.

What Threat Modeling Produces

A threat model produces a list of identified threats, each evaluated for likelihood and impact, with prioritized mitigations that address the highest-risk threats. The mitigations may be architectural decisions — separating components, adding encryption, implementing authentication — or operational controls — monitoring requirements, access reviews, incident response procedures. The threat model becomes a reference document that guides both initial development and ongoing security assessment of the system.

Threat Modeling in DevSecOps

Threat modeling is most impactful when conducted early in the development lifecycle — during architecture and design rather than after development is complete. A threat identified during design costs nothing to mitigate through a different design decision. The same threat discovered post-development may require significant rework. Mature DevSecOps programs conduct threat modeling as a standard component of the design review process for any new system or significant architecture change.

Real-World Example: Threat Modeling Prevents Healthcare API Exposure

A Cloudskope threat modeling engagement for a PE-backed digital health company identified a design decision that would have exposed patient health records through a poorly scoped API. The development team had designed an API that returned complete patient records when queried by appointment ID, planning to filter sensitive fields on the client side. The threat model identified that client-side filtering is not a security control — any client with valid API access could bypass it and access complete records. The design was revised before development, eliminating a HIPAA compliance vulnerability that would have required significant remediation post-deployment.