What is the difference between design review and SAST in application security?

Design review evaluates whether the proposed system is secure before code exists. SAST inspects written code for weaknesses after implementation. Design review targets architectural choices such as authorization logic, data exposure, and trust boundaries, while SAST is better at locating code-level defects. They are complementary, but they solve different problems at different stages.

Why This Matters for Security Teams

Design review and static application security testing solve different parts of the same risk problem, and teams that blur them usually discover gaps late. A design review checks whether the proposed architecture can meet security requirements before implementation begins, while SAST inspects source or compiled code for flaws that already exist. That distinction matters because some failures are structural, such as broken trust boundaries, weak authorization flows, unsafe data handling, or missing segregation between components. Those issues are often invisible to code scanning alone.

For security leaders, the practical question is not whether to choose one control over the other, but how to place each control where it has the most leverage. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it distinguishes between security-by-design expectations and technical testing activities. Design review supports governance and early risk reduction, while SAST supports implementation assurance. Used together, they reduce rework and lower the chance that insecure assumptions survive into production.

In practice, many security teams encounter architectural defects only after code review has already been completed, rather than through intentional design validation.

How It Works in Practice

A design review usually happens during requirements, architecture, or threat modeling stages. The reviewer evaluates whether the proposed system has defensible trust boundaries, clear authorization paths, minimal data exposure, and sensible dependencies. The output is usually a risk decision, an approved pattern, or a set of required changes before coding continues. SAST, by contrast, runs against code artifacts and looks for known insecure patterns such as injection risk, insecure deserialization, weak cryptographic handling, hardcoded secrets, and unsafe error handling. It is strongest when the codebase is readable by the scanner and the rules are tuned to the language and framework.

Security teams get better results when they treat design review as a prevention control and SAST as a defect detection control. That means:

• Using design review to challenge the architecture, data flows, and trust assumptions early.
• Using SAST to validate whether implementation matches secure intent once code exists.
• Feeding recurring SAST findings back into design standards and secure coding guidance.
• Tracking both controls in the SDLC so that security gates are not reduced to a single scanner result.

This distinction aligns well with OWASP guidance on building secure software and with the NIST view that controls should address both design-time and implementation-time risk. The NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue also helps teams map early architecture validation to broader governance expectations, rather than treating it as an informal checklist. For teams that develop APIs, cloud services, or agentic systems, design review is also where trust boundaries and identity assumptions should be tested before code hardens them into production behavior.

These controls tend to break down when teams push architecture decisions directly into fast-moving microservice or platform engineering environments because ownership is fragmented and design assumptions are rarely captured in one place.

Common Variations and Edge Cases

Tighter design governance often increases delivery overhead, requiring organisations to balance early risk reduction against speed and developer autonomy. That tradeoff is real, especially in agile teams that release frequently and resist heavyweight approvals. Current guidance suggests the answer is not to eliminate design review, but to make it proportionate: focus on high-risk changes, new trust boundaries, sensitive data paths, authentication flows, and externally exposed services.

There is no universal standard for exactly how much review is enough. Some organisations use lightweight architecture sign-off, while others combine threat modeling, privacy review, and security architecture review into one stage. SAST has its own edge cases too. It often produces noise in generated code, test fixtures, legacy applications, and polyglot repositories with inconsistent build pipelines. It also cannot reliably prove the absence of a flaw, so it should not be treated as a substitute for code review, dynamic testing, or runtime monitoring. For teams working under NIST SP 800-53 Rev 5 Security and Privacy Controls, the practical move is to define where design review is mandatory and where SAST is required, then use both to cover different failure modes.

In mature programs, the strongest signal is not scanner coverage alone but whether recurring SAST findings are shaping future design decisions. When that feedback loop is missing, the same flaws reappear in each release under different implementation details.

Related resources from NHI Mgmt Group

• What is the difference between SAST and DAST for security teams?
• What is the difference between compliance-driven access review and real identity security?
• What is the difference between role design and effective access review?
• How do security teams tell the difference between a design flaw and an execution problem?