Use a design review to check that the overall architecture has the right controls, a threat model to explore what could go wrong in a specific flow, and a code review to find implementation mistakes. They overlap, but each catches things the others miss. The OWASP insecure design entry explains why relying on code review alone leaves a gap.
What each one is for
Design review. Looks at the plan: components, connections, data storage, configuration and context. The OWASP Secure Product Design Cheat Sheet organizes it into five areas: context, components, connections, code and configuration. The aim is to confirm the structure supports the controls you need.
Threat model. Asks what can go wrong and what to do about it. The OWASP Threat Modeling Cheat Sheet uses four questions and works from a data flow diagram. The aim is a ranked list of threats with owned responses.
Code review. Reads the implementation. It finds bugs such as missing validation or unsafe handling of secrets. OWASP's insecure design entry notes that implementation defects are different from design flaws and have different remedies.
Which to pick
| Situation | Best fit |
|---|---|
| New service or major architecture change | Design review, then threat model |
| New feature touching sign in, permissions or money | Threat model |
| Routine change inside a known design | Code review |
| Unclear scope or new technology | Design review first |
A simple rule of thumb
Ask what kind of mistake you are hunting. A missing control or bad structure is a design question. A flaw in how the control was built is a code question. A weakness that arises only when parts interact in unexpected ways is a threat modeling question.
How they feed each other
A design review can produce a list of areas to threat model. A threat model produces requirements that a code review can check. A code review that finds a surprising pattern can trigger a design discussion. Treat the three as links in a chain, with notes passed along.
Keep each one proportionate
Not every feature needs all three. The OWASP insecure design entry advises threat modeling for critical authentication, access control, business logic and key flows. Everything else can rely on routine code review and your paved road components.
Add automation where it helps
Automated scanning handles the code and dependency side at scale. Safeguard's dependency and SBOM scanning and policy gates can run on every pull request, which frees human reviewers for the design questions. See the gate pull request demo.
Quick check
Can a threat model replace a design review?
Not fully. A threat model is built on a diagram and focuses on threats. A design review also checks components, configuration and context.
Should the same people do all three?
Mixing is good, since fresh eyes help. Keep the author in design and threat modeling and add independent readers for code review.
Sources
- OWASP Secure Product Design Cheat Sheet
- OWASP Threat Modeling Cheat Sheet
- OWASP Top 10 2021, A04 Insecure Design
Last reviewed: 19 October 2026.
