7 Threat Modeling Examples for Secure Design

A threat model is only useful when it changes the build. A static document can describe a system accurately on the day it's written, then become irrelevant as services, APIs, infrastructure, and permissions change. A living model connects the system boundary, attacker or failure scenario, mitigation, evidence, and enforcement point so developers can make safer decisions during delivery.

That distinction has shaped modern threat modeling. Microsoft documented its methodology internally in 1999, and STRIDE, created by Loren Kohnfelder and Praerit Garg in the same year, became a mature, widely cited model that Microsoft adopted by 2002. The historical shift mattered because security moved from occasional expert review toward a repeatable design practice built into development lifecycles. Microsoft's threat-modeling history describes that progression alongside earlier attack-tree work.

The examples below connect concrete artifacts to regulated-sector scenarios, mitigations, pull-request or workflow enforcement, and the continuous updates needed to prevent drift. They cover DFDs, STRIDE, attack trees, abuse cases, personas, supply-chain models, and compliance-driven analysis across FinTech, HealthTech, and media.

1. STRIDE Threat Modeling in CI/CD Pipelines

STRIDE gives developers a shared vocabulary for six threat classes: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Its value isn't the acronym alone. The value comes from attaching each category to a component, data flow, decision, and control that developers can verify while code changes are still reviewable.

Consider a FinTech payment service. A transaction flow might involve a customer session, an API gateway, a payment processor, and a ledger. STRIDE prompts specific questions. Can an attacker spoof the customer or service identity? Can anyone tamper with transaction details between the gateway and processor? Can the institution prove who authorized a transfer? Does an error response disclose sensitive account information? Can abusive requests exhaust processing capacity? Can a service obtain privileges beyond its payment scope?

A HealthTech platform would emphasize Information disclosure around patient records and Repudiation around access decisions. A financial institution may give special attention to transaction attribution and tamper evidence. The categories remain stable, but the data sensitivity, business impact, and required evidence change by sector.

Put STRIDE at the pull request

A useful workflow maps threat names to implementation requirements:

• Tampering: Require cryptographic signing or integrity validation for transaction payloads.
• Repudiation: Require immutable audit events containing the actor, action, and relevant request context.
• Information disclosure: Block logs and responses that expose protected fields.
• Elevation of privilege: Reject changes that broaden service roles without an approved design decision.

The pull request should show the affected component's existing threat context, not just a scanner finding. DevArmor's continuous threat modeling approach is relevant where teams need STRIDE analysis to follow repository and architecture changes, while guardrails can help with risks such as preventing cascading agent failures.

Practical rule: Don't mark a threat as addressed because a control is documented. Verify that the changed code and deployment configuration implement it.

Microsoft's historical work established STRIDE as a repeatable design method, but a current program still needs refresh triggers. Repository changes, altered service boundaries, new identity flows, infrastructure changes, and exposed endpoints should reopen the relevant threat decisions. Without that connection, a CI/CD integration merely produces a newer-looking version of the same stale document.

2. Data Flow Diagram Threat Modeling with Continuous Artifact Extraction

A DFD exposes security decisions at the points where data moves. It maps processes, data stores, external entities, trust boundaries, and the flows connecting them, allowing reviewers to ask where sensitive information could be intercepted, altered, misrouted, or retained.

For a FinTech payment path, trace data from the customer-facing application through the API gateway, transaction processor, clearing service, and ledger. At each boundary, record the required control: authenticated connections, protected transport, field minimization, and an identified audit-record owner. The result is an artifact engineers can compare with service configuration and pull-request changes.

In HealthTech, follow patient information through authentication, records, analytics, and reporting services. Apply consistent sensitivity labels, then distinguish an approved analytics flow from accidental exposure through debugging, caching, or third-party tooling. A media platform can trace content from origin storage through processing, CDN, and caching layers, exposing unauthorized access paths and unexpected persistence.

The diagram should change with the system, not wait for a workshop.

Teams can extract architecture context from repository metadata, service definitions, orchestration configuration, and infrastructure templates. Continuous extraction will not decide whether a trust boundary is correct, whether analytics needs a field, or whether a vendor assumption remains valid. It does reduce the chance that a new service or changed API disappears from the model because nobody edited a diagram by hand. The threat modeling process that connects architecture to decisions treats the DFD as a workflow artifact, while AI-powered diagram creation tools can accelerate visual updates. Engineers still need to validate boundaries and data classifications.

Tie each important flow to a verification record:

• Trust boundary: Test authentication, authorization, and encryption at the boundary.
• Sensitive flow: Verify field-level minimization and logging rules.
• Data store: Check retention, access roles, backup exposure, and integrity requirements.
• External entity: Record contractual, technical, and operational assumptions.

For regulated services, these records connect the diagram to a concrete mitigation and its enforcement point. A pull request that adds a reporting route should surface the affected flow, required data fields, identity checks, encryption expectations, and audit event. Reviewers can then require configuration, test, or policy evidence before approving the change.

Refresh extraction and review after service-boundary changes, altered schemas, new vendors, infrastructure updates, or changed retention rules. That cadence prevents the DFD from describing an earlier architecture while the regulated data path has already changed.

3. Attack Tree Analysis for Regulatory Compliance Documentation

Attack trees turn a regulated business objective into reviewable control decisions. Start with an attacker goal such as unauthorized fund transfer, patient-data exfiltration, or payment-data tampering. Decompose it into required conditions, alternative routes, and combinations an attacker must satisfy.

For a bank, the tree can show which controls interrupt each path to an unauthorized transfer. A HealthTech provider can document how identity compromise, authorization failure, excessive data access, and weak auditability combine into patient-data exposure. A payments team can trace how a modified pre-authorization request might reach settlement. The same method applies to document workflows such as Head of Agents document intake, where unauthorized access, altered records, or missing review evidence become distinct branches.

The artifact is useful only when each leaf produces an owner, a mitigation, and evidence. Researchers in an enterprise threat-modeling case study assessed output accuracy, task completion time, similarity between participants' identified causes of harm, and the quality of actionable defense plans. The case study offers a pattern for reviewing decision quality and execution speed rather than checking whether a diagram exists.

Convert attack leaves into workflow checks

Map every atomic step to a control that developers and reviewers can verify:

• Credential compromise: Require phishing-resistant authentication, scoped credentials, and detection.
• Unauthorized transaction: Bind authorization to the transaction and retain approval evidence.
• Audit deletion: Store logs with independent retention and integrity controls.
• API manipulation: Validate signed requests and reject unexpected state transitions.

AND and OR logic clarifies whether an attacker needs several conditions or can choose among alternate paths. Keep the tree in an auditor-readable diagram and structured data, so automation can identify affected nodes as code and infrastructure change.

A tree that names an attack path but doesn't identify a control owner is risk documentation, not risk management.

A pull request that changes authentication, payment state, data access, or audit behavior should identify the related nodes. Reviewers can check whether the change weakens a choke point, adds a branch, or invalidates existing evidence. Regenerate or reassess the tree after architecture changes, new integrations, altered approval paths, or revised compliance requirements. That maintenance keeps the model aligned with the system instead of preserving an obsolete audit snapshot.

4. Abuse Case and Misuse Case Modeling for Policy Enforcement

An abuse case starts with a legitimate feature and specifies how it could produce an unauthorized result. It exposes failures that ordinary authentication and authorization checks may miss, then turns those failures into controls developers can verify.

For a FinTech transfer flow, model a user changing the recipient after the interface shows an approved beneficiary. The mitigation requires more than endpoint protection. Bind the transaction to the approved recipient, validate the change on the server, request step-up approval when needed, and record the approved details in an audit event. A pull request that changes transfer-state logic should trigger checks for each control.

HealthTech presents a different misuse path. An authenticated patient alters an object identifier in an API request and receives another patient's record. The required rule is object-level authorization: the server must confirm that the record belongs to the authenticated subject or that an explicitly authorized role permits access. For a media platform, unlimited download requests after a user disables client-side limits call for server-enforced quotas, rate limits, and abuse detection.

Turn harmful outcomes into deny rules

Write each scenario as an outcome the system must prevent. Then connect it to a policy and an enforcement point:

• Account change abuse: Reject unvalidated recipient changes or require renewed approval.
• Object-level access abuse: Block merges that omit authorization checks tied to the authenticated session.
• Download abuse: Require server-enforced quotas and rate limits.
• Audit bypass: Reject sensitive code paths that do not emit traceable events.

High-confidence rules can block a pull request. A rule with uncertain intent should request design review instead, preserving developer flow while sending the decision to a human. Policy-as-code examples from DevArmor show how approved security decisions can become enforceable rules.

Capture the misuse case during feature planning. Ask how an insider, compromised account, automated client, or external attacker could use the proposed behavior in an unintended way. Store the feature ticket, scenario, approved mitigation, policy identifier, and verification result together. Reassess them when APIs, permissions, workflows, or regulatory obligations change.

Policy enforcement also needs maintenance. Review blocked pull requests, exceptions, and false positives. Repeated friction may indicate an overly broad rule or a control that needs redesign. Refine the policy without weakening the protection, so developers can follow the intended path rather than bypassing the checks.

5. Persona-Based Threat Scenarios with AI-Assisted Code Generation Guardrails

A persona-based model turns an abstract attacker into a defined set of permissions, decisions, and likely behaviors. A disgruntled insider, external opportunist, compromised supplier, or highly capable adversary may follow different paths because each has different access and objectives. Record those differences before translating them into code and workflow controls.

For a financial-services application, model a disgruntled trader who can view markets and initiate selected workflows but cannot bypass approvals. Review generated changes for removed approval checks, expanded service roles, and exposed transaction endpoints. Route those findings to security review before merge, rather than relying on a general code review to detect them.

A HealthTech data thief presents a different scenario. Generated access code should enforce role-based authorization, narrow queries, logging, and export controls for bulk patient records. In a media platform, the persona may be a content pirate. The guardrail should flag code that bypasses entitlement checks, extracts protected media, or disables server-side enforcement.

Treat the coding agent as a capability

AI-assisted development introduces a benign-agent scenario. The coding agent may misunderstand a requirement, copy an unsafe pattern, trust an unverified instruction, or alter a security-sensitive function without recognizing its effect. The model should therefore assess what the agent can reach and change, not only whether a human actor appears malicious.

A useful persona record connects four artifacts:

• Access: Which repositories, secrets, tools, environments, and data can the actor reach?
• Capability: Can the actor alter code, invoke APIs, approve changes, or influence deployment?
• Objective: What outcome would make the scenario successful?
• Guardrail: Which code pattern, permission, or workflow decision should prevent it?

Apply deny rules to high-confidence patterns and document exceptions. An identity migration may resemble privilege expansion, so require explicit design approval before merge instead of blocking every matching change or accepting it automatically. The pull request should retain the scenario, affected policy, reviewer decision, and verification result.

Review the model whenever agent tools, repository permissions, generated-code workflows, or deployment targets change. Recheck IDE guidance, pull-request checks, and deployment controls against the approved boundary, then update the persona record when those controls drift.

6. Threat Modeling for Third-Party and Supply Chain Risk Assessment

A supply-chain model begins with the dependency's trust boundary, then records what the component can access, change, and expose. Include libraries, APIs, vendors, hosted platforms, build tools, and external data sources, even when the architecture diagram treats them as outside the organization.

For a FinTech payment library, a compromised dependency could influence cryptographic operations, expose transaction data, or reach credentials through the application's normal execution path. The artifact should connect each risk to signature verification, narrowly scoped usage, dependency integrity checks, and monitoring for unexpected behavior. A pull request that introduces or changes the library should include that scenario, its owner, and the reviewer's decision.

A HealthTech logging vendor creates a different failure mode. Compromise or outage could remove reliable evidence of access to patient data. Retain an independent local stream, protect log integrity, and alert when the external service stops receiving events. Treat the alert and recovery procedure as part of the model, not as an operational detail left outside it.

For a media platform, video-processing and codec libraries require analysis of vulnerable parsing, remote code execution, and malicious binaries. Version pinning, binary scanning, sandboxing, and controlled update review limit the blast radius. They do not replace an explicit record of reachable files, network destinations, credentials, and deployment permissions.

Connect the SBOM to enforcement

An SBOM must describe the actual build output, not only a manually maintained dependency list. Combine it with API contracts and vendor assessments, then classify components by business impact. Authentication, encryption, payment, and identity dependencies warrant stricter review than development-only utilities.

Enforce the model at points developers already use:

• Dependency introduction: Require ownership, provenance, license review, and a threat-model impact statement.
• Version change: Recheck exposed interfaces, permissions, update channels, and prior assumptions.
• Build output: Verify that the deployed artifact matches the reviewed dependency set.
• Runtime access: Sandbox high-risk components and restrict network and credential access.

Cover vendor outages, changed API behavior, compromised update channels, and unavailable audit evidence. A vendor assessment informs the decision, but technical controls inside the environment still determine the practical exposure.

Refresh records from dependency manifests, SBOM changes, lockfiles, container images, API contracts, and vendor notifications. Require a supply-chain scenario in any pull request adding a payment or identity dependency. At deployment, verify that the approved component and version are present, then reopen the model when the vendor, interface, permission boundary, or build process changes.

7. Regulatory Scenario Modeling for Compliance-Driven Threat Enumeration

A compliance requirement becomes actionable only when the model shows how a failure could occur, what control prevents it, and which evidence proves the control works. This approach gives auditors, examiners, and customers a traceable path from obligation to architecture, implementation, and verification.

A FinTech company can translate a logical-access requirement into a scenario where an unauthorized person reaches financial records. The model then assigns controls for authentication, authorization, segmentation, monitoring, and review. In HealthTech, a security-rule objective may become unauthorized access to a patient record. The resulting design can include role-based access control, audit logging, access reviews, and incident evidence.

For a media platform handling personal data, a security-of-processing obligation can be modeled as interception during transit. The technical response may include transport encryption, certificate validation, access controls, and defined handling for data moving across regions. The control set depends on the architecture and legal interpretation. Preserve the original requirement and the organization's approved decision so later changes do not erase that context.

Make the evidence chain executable

A useful mapping record connects five artifacts:

• Requirement: Preserve the exact control objective or requirement text.
• Threat scenario: Describe an observable failure with a harmful outcome.
• Technical control: Identify the architecture or platform control that addresses it.
• Implementation: Point to the code, configuration, or infrastructure change.
• Evidence: Record the test, review, deployment artifact, or audit event that verifies it.

Write failure conditions precisely. “Access control exists” gives a reviewer little to test. “A user can retrieve another subject's record because object ownership is not checked server-side” identifies the defect, the expected fix, and the test case.

Pull requests should expose the compliance context behind a security rule. A change affecting identity, retention, encryption, or auditability should link its requirement, scenario, control, and verification evidence. Reviewers can then assess whether the implementation addresses the stated failure rather than merely satisfying a control label. Deployment checks should confirm that approved settings remain present after configuration changes.

Requirements and examination priorities change. Reopen the mapping when interpretations, data uses, vendors, or system boundaries change, and refresh evidence from the running system. This keeps the audit record tied to current behavior instead of preserving an attractive but outdated compliance packet.

Comparison of 7 Threat Modeling Approaches

Turn the Model Into a Decision That Survives Change

Start with a DFD when you need to understand where sensitive data travels, which systems receive it, and where trust boundaries require controls. Add STRIDE when the architecture has familiar components and you need a repeatable category-based review across identities, flows, stores, and services. STRIDE is especially effective when its findings map directly to pull-request rules and implementation tests.

Start with an attack tree when the business risk is expressed as a concrete attacker goal, such as unauthorized transfer or patient-data exfiltration. Use an abuse case when the danger comes from misusing a legitimate feature. Choose a persona model when access, motivation, and capability differ sharply between insiders, external users, suppliers, and coding agents.

A supply-chain model should lead when dependencies, vendors, APIs, hosted services, or build artifacts create the main uncertainty. Use a regulatory scenario when the primary question is how a control requirement becomes an implemented, testable, auditable decision. These methods work together. A DFD can reveal the flow, STRIDE can classify the threat, an attack tree can decompose the goal, and policy-as-code can enforce the approved mitigation.

The operating loop is straightforward:

1. Extract context from tickets, design documents, repositories, service metadata, infrastructure definitions, and deployment artifacts.
2. Record threats and decisions with the affected component, scenario, control owner, assumptions, and approved mitigation.
3. Map decisions to policy-as-code so important requirements can appear in planning tools, IDEs, source control, and pull requests.
4. Verify implementation in code review and deployment workflows, not only in a security document.
5. Refresh on change when IaC, CI/CD, identity relationships, APIs, dependencies, repositories, or public exposure changes.

Independent security-metrics guidance recommends tracking design-review coverage, the percentage of critical applications with a current threat model, and the number of controls deployed as a direct result of threat modeling. Those measures help shift attention from document production to implemented outcomes. The metrics guidance also emphasizes controls, exception debt, and review churn as useful signals of program health.

Continuous updates are now central to cloud threat modeling. Guidance from the Cloud Security Alliance on continuous cloud threat modeling recommends connecting refreshes to changes such as Terraform plans, public exposure, and policy-as-code gates. That principle applies beyond cloud infrastructure. A threat model should follow the artifacts that define the running system.

DevArmor is relevant where teams need one living security context across planning, coding, source control, and deployment. Its platform can generate threat models from tickets, design documents, repositories, and service metadata, surface design reviews in developer workflows, enforce approved decisions through pull requests, and retain traceable evidence for regulated teams. The important design choice isn't the product. It's making the threat decision part of the delivery path instead of leaving it in a document repository.

Use DevArmor to connect threat models, security design reviews, and policy-as-code enforcement across your software delivery workflow. Visit DevArmor to keep architecture decisions synchronized with repositories and planning artifacts, then give developers and coding agents security context where they build.