The cheapest security review you are probably not doing

There is a predictable arc to how small teams discover their security weaknesses. A feature ships, it works, everyone moves on — and then months later a penetration test, a bug-bounty report, or an actual incident reveals that the design had a hole in it from day one. The fix at that point is expensive: it means re-architecting live code, migrating data, and explaining to a customer why their information was exposed. The same flaw, spotted in a whiteboard conversation before a line of code existed, would have cost an afternoon. That conversation has a name — threat modeling — and it is the highest-return security activity most lean teams skip because they assume it requires a specialist or a heavyweight process. It does not. This article is general education on how to run one lightly. It pairs naturally with the design-time discipline of a secure SDLC; threat modeling is the "think before you build" half of that story.

Four questions, and nothing more complicated than that

Strip away the frameworks and threat modeling is four plain questions, asked in order, about whatever you are about to build or change:

  1. What are we working on? Draw the system — the components, the data stores, the users and external services, and the arrows showing how data flows between them. A rough diagram on a whiteboard is genuinely enough; the goal is shared understanding, not a polished artifact.
  2. What can go wrong? Walk the diagram and brainstorm how each piece could be abused. This is the creative heart of the exercise, and it is where a light checklist helps a team that does not think about attackers all day.
  3. What are we going to do about it? For each plausible threat, decide: mitigate it now, mitigate it later, accept it deliberately, or transfer it. Most threats will not get fixed immediately, and that is fine — a decision is the deliverable, not a fix.
  4. Did we do a good enough job? Revisit the model when the system changes materially, and check that the mitigations you promised actually shipped.

Notice that three of the four questions are just structured conversation. The only place teams reliably get stuck is question two — "what can go wrong?" — because staring at a blank diagram and imagining attacks is hard without a prompt. That is what a threat taxonomy is for.

STRIDE: a checklist so you do not have to be creative on demand

STRIDE is a mnemonic — originally from Microsoft — that gives you six categories of threat to check each component against, so "what can go wrong?" becomes a checklist instead of a staring contest. For a lean team, that structure is the whole value:

  • S — Spoofing. Can someone pretend to be a user, a service, or a system they are not? This is where weak authentication and missing MFA show up, and where service-account identity matters.
  • T — Tampering. Can data be modified in transit or at rest by someone who should not be able to? Points you at encryption in transit, integrity checks, and input validation.
  • R — Repudiation. Could someone take an action and later plausibly deny it because nothing recorded it? This is the case for logging and an audit trail.
  • I — Information disclosure. Can someone read data they should not — through broken access control, a misconfiguration, or an over-broad API? Ties directly to least privilege and cloud misconfiguration.
  • D — Denial of service. Can someone exhaust or knock over the system? Points at rate limiting, quotas, and availability defenses.
  • E — Elevation of privilege. Can a low-privilege user gain higher privileges than intended? The most severe category, and the reason privilege boundaries deserve scrutiny.

You do not memorize attacks — you walk each box of your diagram and ask the six questions. "Our API endpoint — can it be spoofed? Tampered with? Does it log enough to prevent repudiation? Can it disclose data it shouldn't? Can it be DoS'd? Can a normal user elevate?" Most answers will be "we handle that," and the few that are "hmm, actually…" are exactly the findings the exercise exists to surface.

Where to point the exercise, and how deep to go

A lean team cannot threat-model everything, so the skill is aiming the exercise where the payoff is highest. Reach for it when:

  • You are designing a new feature that touches sensitive data, authentication, payments, or an external integration.
  • You are making a material architecture change — a new data store, a new third-party service, a new public endpoint, a change to your trust boundaries.
  • You are onboarding a new external dependency whose compromise would matter, connecting to the discipline of software-supply-chain security.

Keep the depth proportional. A single new endpoint might be a fifteen-minute conversation; a new payment flow deserves an hour with the right people in the room. The people matter more than the formality: someone who understands the system's design, someone who understands the data's sensitivity, and — ideally — someone willing to think like an attacker. You do not need a dedicated security engineer to start; you need the discipline to ask the four questions honestly before the code is written.

The output is tracked work, not a diagram in a drawer

The most common way threat modeling fails is that the session happens, a diagram gets drawn, threats get discussed — and then all of it evaporates because nothing was written down as work. A threat you identified and forgot is arguably worse than one you never found, because you spent the effort and got none of the protection. The discipline that makes the exercise pay off is the same one that carries every finding:

  • Every unmitigated threat becomes a tracked item with an owner and a decision — remediate on a schedule, or formally accept the risk with a named person signing off. A threat with no owner is a threat you will rediscover in an incident report.
  • Feed threats into the same queue as everything else. A weakness found in a whiteboard session and a weakness found by a scanner are both just findings; running them through one findings workflow means design-time risks get the same triage, prioritization, and follow-through as everything else instead of living in meeting notes.
  • Close the loop when the system changes. The fourth question — "did we do a good enough job?" — is where you confirm the mitigations shipped and re-open the model when the architecture shifts. Continuous monitoring is what tells you whether a control you designed for is still actually in place.

This is where a platform earns its keep, and where it does not. Ours cannot draw your data-flow diagram or imagine your attackers for you — that judgment is the team's. What it can do is give every threat you identify a home: an owned, dated, tracked finding that shows up worst-first alongside your scan results and compliance gaps, with its evidence and its acceptance decision recorded. The thinking stays human; the platform makes sure the thinking does not evaporate.

Threat modeling is the cheapest security review a lean team can run — a structured, hour-long conversation about what could go wrong before you build, so fixes land in the design instead of the incident report. Four questions (what are we building, what can go wrong, what will we do, did we do enough), a STRIDE checklist so "what can go wrong" stops being a staring contest, and — the part teams skip — every identified threat turned into a tracked, owned finding rather than a diagram in a drawer. No tool does the thinking; a good one keeps the thinking from being wasted.