Threat Modeling for Secure Software Development: STRIDE, PASTA & Beyond

What Is Threat Modeling?

Threat modeling is the structured process of identifying what can go wrong in a system, how likely it is, and what to do about it. Unlike reactive security measures (penetration testing, vulnerability scanning), threat modeling is proactive by design—it happens during architecture and design, before vulnerabilities are baked into the codebase.

At its core, every threat model answers four questions (as defined by Adam Shostack):

1. What are we building? — System architecture, data flows, trust boundaries.
2. What can go wrong? — Systematic identification of threats.
3. What are we going to do about it? — Mitigations, acceptance, or transfer.
4. Did we do a good enough job? — Validation and continuous improvement.

STRIDE: The Industry Standard

Developed at Microsoft in 1999 and still the most widely used framework, STRIDE is a mnemonic for six categories of threats. Each category maps to a violation of a specific security property:

The power of STRIDE is its simplicity. For each component in your Data Flow Diagram (DFD), you systematically ask: "Can this component be spoofed? Tampered with? Can it leak information?" This mechanical process ensures you don't miss entire threat categories.

PASTA: Risk-Centric Threat Modeling

While STRIDE is threat-centric (focused on what can go wrong), PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric, seven-stage methodology that aligns threat analysis with business objectives and attacker behavior.

1. Define Objectives: Identify business goals, compliance requirements (e.g., CMMC 2.0), and risk appetite.
2. Define Technical Scope: Map the application architecture, APIs, infrastructure, and third-party dependencies.
3. Application Decomposition: Create DFDs showing data flows, trust boundaries, entry points, and assets.
4. Threat Analysis: Research known threats to the technologies in scope using CTI feeds and MITRE ATT&CK.
5. Vulnerability Analysis: Map existing vulnerabilities (CVEs, misconfigurations) to the identified threats.
6. Attack Modeling: Build attack trees that simulate realistic attack paths from initial access to impact.
7. Risk & Impact Analysis: Score each threat by likelihood × impact to prioritize remediation.

PASTA is particularly valuable for defense and enterprise systems where threat models must be traceable to compliance frameworks and where attacker sophistication (nation-state, APT) justifies the deeper analysis.

Attack Trees: Visualizing the Kill Chain

An attack tree is a hierarchical diagram where the root node represents the attacker's goal, and each branch represents a different path to achieve it. Leaf nodes are the atomic attack steps.

Goal: Exfiltrate Customer PII from Database
├── Path 1: SQL Injection via Search API
│   ├── Find unparameterized query in /api/search
│   ├── Extract table schema via UNION-based injection
│   └── Dump customer_records table
├── Path 2: Compromise Developer Credentials
│   ├── Phish developer via spear-phishing email
│   ├── Harvest credentials from compromised workstation
│   └── Access production DB via VPN + stolen creds
└── Path 3: Exploit Exposed Backup
    ├── Discover S3 bucket via subdomain enumeration
    ├── Access unencrypted database backup
    └── Download and extract PII offline

Attack trees make it immediately visible which paths are cheapest for an attacker and which mitigations provide the most coverage. Blocking a single node high in the tree can eliminate entire branches of attack.

Data Flow Diagrams: The Foundation

Every threat modeling exercise begins with a Data Flow Diagram (DFD). A DFD maps how data moves through your system and where it crosses trust boundaries—the points where the level of trust changes (e.g., from the public internet to your API gateway, or from your application to a third-party service).

DFD elements:

• External Entities: Users, third-party APIs, external systems (drawn as rectangles).
• Processes: Application components that transform data (drawn as circles).
• Data Stores: Databases, file systems, caches (drawn as parallel lines).
• Data Flows: Arrows showing the movement of data between elements.
• Trust Boundaries: Dashed lines showing where privilege levels change.

The most critical threats almost always appear at trust boundaries. An API call crossing from the public internet into your backend is a trust boundary. Data moving from your application to a third-party SaaS is a trust boundary. These are where authentication, validation, and encryption must be strongest.

Integrating Threat Modeling into DevSecOps

Traditional threat modeling was a heavyweight, document-driven process performed once during design and then forgotten. Modern DevSecOps practices require continuous threat modeling that evolves with the codebase:

• Threat Model as Code: Tools like OWASP Threat Dragon and Microsoft Threat Modeling Tool allow DFDs and threat models to be stored in version control alongside the application code.
• PR-triggered reviews: When a pull request modifies a trust boundary (e.g., adds a new API endpoint, changes authentication flow), flag it for a lightweight threat model review.
• Automated threat enumeration: Tools like Threagile can ingest YAML architecture definitions and automatically enumerate STRIDE threats, generating a risk report in CI/CD.
• Link to backlog: Every identified threat should generate a tracked work item (Jira, GitLab issue) with a risk score and remediation deadline, ensuring accountability.

# Example: Threagile CI/CD integration
# Run threat model analysis on every architecture change
threagile analyze \
  --model architecture.yaml \
  --output threat-report.pdf \
  --risk-tracking risk-tracking.yaml

Prioritizing Threats: DREAD and Beyond

Not all threats are equal. After enumeration, you need a scoring system to prioritize remediation. The classic DREAD model scores each threat on five dimensions (1-10):

• Damage Potential — How severe is the impact?
• Reproducibility — How easy is it to reproduce?
• Exploitability — How easy is it to exploit?
• Affected Users — How many users are impacted?
• Discoverability — How easy is it to discover?

While DREAD provides a quick heuristic, many organizations now prefer CVSS-based scoring or risk matrices that map likelihood (threat agent capability, attack vector) against impact (data sensitivity, regulatory consequences). For defense systems, impact must account for mission criticality—a compromised C2 system has a fundamentally different risk profile than a compromised internal wiki.

Threat Modeling for Common Architectures

Microservices & APIs

In microservices architectures, the attack surface expands with every service-to-service communication channel. Key threats include: broken authentication between services, excessive data exposure in API responses, mass assignment vulnerabilities, and lateral movement after compromising a single service. Each API endpoint is a trust boundary that requires its own threat analysis.

AI/ML Pipelines

AI systems introduce novel threat categories: model poisoning via training data manipulation, adversarial inputs designed to cause misclassification, model theft through prediction API queries, and data leakage from model memorization. STRIDE alone doesn't capture these—teams should supplement with AI-specific threat libraries like MITRE ATLAS (Adversarial Threat Landscape for AI Systems).

Air-Gapped & Defense Systems

For air-gapped environments, threat models must account for supply chain compromise (malicious code introduced via approved media transfer), insider threats with physical access, and electromagnetic emanation (TEMPEST). The trust boundary model shifts from network-centric to physical-centric: every USB drive, every firmware update, and every maintenance window is a trust boundary crossing.

A Practical Checklist for Your First Threat Model

1. Draw the DFD — Map all components, data flows, and trust boundaries. Keep it at 1-2 levels of abstraction.
2. Enumerate threats with STRIDE — Walk through each DFD element and ask the six STRIDE questions.
3. Build attack trees for the top 3-5 most critical assets.
4. Score each threat using DREAD or a risk matrix. Don't spend time on threats that are both low-impact and low-likelihood.
5. Define mitigations — For each high-priority threat, specify a concrete control (input validation, mTLS, rate limiting, etc.).
6. Create tracked work items — Every mitigation becomes a task with an owner and deadline.
7. Store the model in version control and schedule reviews when the architecture changes.
8. Validate with testing — Use the threat model to generate test cases for penetration testing and security reviews.

Alterra Solutions' Perspective

At Alterra, threat modeling isn't a checkbox—it's the first artifact we produce on every engagement. For our defense clients, we build threat models that map directly to DISA STIG controls and NIST 800-171 requirements, ensuring that every security control has a traceable justification rooted in a real threat. The result: systems that are secure by design, not secure by accident.

If your team is building software where a breach isn't just a business problem but a mission-critical failure, let's talk about how threat modeling fits into your SDLC.