threat modeling basics for a new feature

threat modeling basics for a new feature

TL;DR

Threat modeling is a 45-minute whiteboard session that asks "how would someone break this feature" before you build it. Sketch the data flow, mark where trust changes, brainstorm attacks with a simple framework, and walk out with a ranked list of mitigations and owners. One page of notes beats a 20-page document nobody reads.

threat modeling basics for a new feature

Use this when

• you are about to build or launch a new feature
• a design review needs a security pass
• you want to catch design flaws while they are still cheap
• the team has never threat-modeled and needs a starting point

Not for this skill when

• the feature already shipped and you want it tested (that is a pentest)
• you need a compliance artifact for an auditor (that is a different document)
• the "feature" is the entire product (scope it down or you will never finish)
• you want vulnerability scanning of running code (that is a scanner's job)

Steps

1. Draw the data flow. User, client, API, database, third parties: boxes and arrows on one diagram, nothing fancy. If you cant draw it, you dont understand it well enough to secure it.

1. Mark the trust boundaries. Everywhere data crosses from one owner to another: browser to API, your API to a vendor, your service to the database. Attacks live at boundaries, so this is where your attention goes.

1. List what you are protecting. Which data, whose, and what happens if it leaks or gets tampered with. This sets the stakes and stops the session from treating every finding as equal.

1. Brainstorm attacks with STRIDE-lite. For each part of the diagram, ask: spoofing (fake identity), tampering (changed data), repudiation (no audit trail), information disclosure (leaks), denial of service, elevation of privilege. One or two ideas per category is plenty; you are not writing a textbook.

1. Rank by likelihood times impact, informally. Dont build a spreadsheet; get the room to agree on the top three risks. If the room cant agree, the loudest risk usually isnt the real one, so ask "what would embarrass us on the front page."

1. Assign mitigations with owners. "Add rate limiting on the export endpoint, owner: Sam, before launch." Every mitigation gets a name and a deadline. Unowned mitigations dont happen.

Variant: threat modeling an AI feature

Add two categories to the brainstorm: prompt injection (untrusted input steering the model) and training-data leakage (the model repeating sensitive data it saw). The data flow diagram needs a box for the model and arrows for what goes in and out of it.

Variant: threat modeling a third-party integration

The trust boundary with the vendor is the whole session. Ask what the vendor can access, what happens when their credentials leak, and what your blast radius is if they get breached. Read their security docs with skepticism.

Variant: threat modeling a mobile app

Device trust is the twist: the client is in the attacker's hands. Assume the app binary is reverse-engineered and the device is rooted, then ask what breaks. Anything the app "hides" on-device is not hidden.

Why this happens

Fixing a design flaw after launch costs far more than sketching it on a whiteboard. Most breaches trace back to design decisions, not coding typos: missing auth on an endpoint, trust in client-side checks, data flowing somewhere nobody mapped.

Edge cases and pitfalls

• Dont threat-model the whole product. Scope to the new feature or the session never ends and nobody comes back for the next one.
• Revisit when the design changes materially. A threat model of last quarter's design is a historical document, not a security control.
• Include one engineer who will actually build it. Mitigations designed without the builder die on contact with the code.
• A threat model is a living note, not a compliance checkbox. If it only gets read by auditors, it failed.
• Timebox it. Forty-five minutes with a timer beats three hours of drifting. You can always schedule a second session for the hard parts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EbTMbaJXeJ89qEGgm0vmFw