Prerequisites

Threat modeling is a design activity rather than a coding exercise, but the following background makes it far more effective:

What Is Threat Modeling?

Threat modeling is a structured process for examining a system design, identifying how it could be attacked or misused, and deciding which defenses are justified. It is a reasoning activity performed on the architecture itself, ideally before the system is built and repeated as the design evolves.

The goal is not to imagine every conceivable attack. The goal is to find realistic weaknesses early, while changing the design is still inexpensive.

Why Threat Modeling Matters

Step 1: Identify Assets

An asset is anything worth protecting. Before discussing attacks, the team should agree on what actually matters in the system.

Step 2: Model the System

The second step is to describe the system accurately enough to reason about it. A data-flow view is usually more useful than a deployment diagram because attacks follow data and requests.

Trust Boundaries in Detail

A trust boundary is any place where data or a request moves from a less trusted context into a more trusted one. Every crossing requires validation, authentication, or authorization decisions.

Step 3: Identify Threats with STRIDE

STRIDE is a widely used mnemonic that helps teams reason about categories of threats rather than relying on memory or intuition. It is applied to each component, data store, and data flow.

Applying STRIDE Systematically

Walk through each element of the model and ask the six questions. A structured pass produces more complete coverage than an open-ended discussion.

Step 4: Consider Attacker Profiles

Different adversaries have different capabilities, motives, and persistence. Modeling them prevents a design that defends only against the least sophisticated case.

Step 5: Prioritize the Risks

Not every identified threat deserves equal investment. Risk prioritization directs effort toward issues with meaningful likelihood and impact.

Impact may include data exposure, financial loss, service disruption, regulatory consequences, and erosion of user trust. Likelihood depends on exposure, attacker effort, and the presence of existing controls.

Response Options

Step 6: Select Layered Controls

Effective designs layer three kinds of controls. Preventive controls stop an action, detective controls reveal that something happened, and recovery controls restore a safe state.

Recording the Threat Model

A threat model is only useful if it is written down, reviewed, and kept current. A structured, versioned document allows the model to evolve alongside the architecture.

{
    "system": "product-search-platform",
    "version": "2026.09",
    "owner": "search-platform-team",
    "assets": [
        "product-catalog",
        "customer-accounts",
        "search-index",
        "audit-logs"
    ],
    "trustBoundaries": [
        "internet-to-gateway",
        "gateway-to-services",
        "service-to-database",
        "pipeline-to-search-index"
    ],
    "threats": [
        {
            "id": "THR-014",
            "component": "search-api",
            "category": "InformationDisclosure",
            "description": "Restricted documents could be returned if index permission filters are not applied.",
            "likelihood": "Medium",
            "impact": "High",
            "response": "Mitigate",
            "controls": [
                "index-level permission filters",
                "authorization check at query time",
                "automated permission regression tests"
            ],
            "status": "Planned",
            "reviewDate": "2026-12-01"
        }
    ]
}

Each entry should identify the affected component, the threat category, the assessed risk, the chosen response, the concrete controls, the current status, and the next review date.

Tracking Threats in a Database

CREATE TABLE threat_model_entries (
    threat_id        VARCHAR(20) PRIMARY KEY,
    system_name      VARCHAR(100) NOT NULL,
    component        VARCHAR(100) NOT NULL,
    stride_category  VARCHAR(30)  NOT NULL,
    description      TEXT         NOT NULL,
    likelihood       VARCHAR(10)  NOT NULL,
    impact           VARCHAR(10)  NOT NULL,
    response_type    VARCHAR(20)  NOT NULL,
    control_summary  TEXT         NOT NULL,
    owner            VARCHAR(100) NOT NULL,
    status           VARCHAR(20)  NOT NULL,
    created_at       TIMESTAMP    NOT NULL,
    review_due_at    TIMESTAMP    NOT NULL
);

SELECT
    threat_id,
    component,
    stride_category,
    likelihood,
    impact,
    owner,
    review_due_at
FROM threat_model_entries
WHERE status <> 'Implemented'
  AND impact = 'High'
ORDER BY review_due_at;

Storing threats as tracked records allows them to be reviewed, assigned, reported, and revisited rather than forgotten after the initial design meeting.

Turning Threats into Tests

A threat model becomes durable when its conclusions are encoded as automated tests. This prevents a mitigated risk from silently reappearing during later refactoring.

describe("search authorization boundary", function () {
    it("excludes documents the caller cannot access", async function () {
        const restrictedDocumentId =
            await createRestrictedDocument({ owner: "user-a" });

        const response = await searchAsUser("user-b", {
            query: "quarterly plan"
        });

        const returnedIds = response.results.map(function (item) {
            return item.documentId;
        });

        expect(returnedIds).not.toContain(restrictedDocumentId);
    });

    it("rejects requests without a valid identity", async function () {
        const response = await searchWithoutCredentials({
            query: "quarterly plan"
        });

        expect(response.statusCode).toBe(401);
    });
});

Threat Modeling a Search and Data Pipeline

Search and ranking systems deserve particular attention because they copy data across multiple stores, each with its own access model.

Abuse Cases Versus Use Cases

A use case describes what a legitimate user should accomplish. An abuse case describes how the same capability could be exploited. Writing both reveals gaps that functional requirements miss.

When to Perform Threat Modeling

Threat modeling is most valuable as a recurring practice rather than a one-time milestone. Architecture changes routinely introduce new boundaries and new exposure.

Common Mistakes

System Design Interview Discussion

Threat Modeling Checklist

Knowledge Check

Summary

Threat modeling is a structured design activity that answers four questions: what is being built, what can go wrong, what will be done about it, and whether the work was done well.

The process begins by naming assets and modeling components, data stores, data flows, and trust boundaries. STRIDE then provides a repeatable way to identify spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation concerns across each element.

Identified threats are prioritized by likelihood and impact, then addressed through mitigation, elimination, transfer, or explicit acceptance. Strong designs layer preventive, detective, and recovery controls rather than depending on a single check.

In search and data-pipeline architectures, particular attention belongs on derived stores, where permission context, deletion propagation, and export boundaries are most frequently lost.