Security design review

Do this

1. Define which designs need review

   Write the triggers down: a new service or external integration, a new trust boundary, changes to authentication, authorization or tenant rules, new sensitive data, money movement, admin or support paths, and departures from the standard patterns (Secure design patterns). Smaller changes can rely on the team's own threat model.

2. Collect the review packet

   Ask the designers for the design document, the data-flow diagram with trust boundaries, the threat model and its responses (Threat modeling), the security requirements, the data classes and any departures from standard patterns. Without a diagram, the reviewer cannot see who chooses each tenant or object ID.

3. Choose a reviewer who did not design it

   NIST SSDF task PW.2.1 calls for a qualified person who was not involved with the design, automated processes in the toolchain, or both. An AppSec engineer, an architect or a security champion from another team can do it; keep the designers in the room to answer questions.

4. Check the design against the requirements

   For each security requirement, find where the design meets it, interface by interface. Check the general mechanisms OWASP SAMM lists for architecture validation: authentication, authorization, user and rights management, secure communication, data protection, key management and logging. For each identifier, ask who chooses it and what verifies it.

5. Check each threat has a design-level answer

   Walk the threat list and name the design feature that counters each threat, as SAMM's Architecture Assessment practice describes. Ask whether the model missed anything: background jobs, admin tools, caches and partner callbacks are common gaps. Check failure handling: what happens when a dependency times out or a permission check throws an error.

6. Record the findings and a decision

   File each finding as an issue with an owner and the part of the design it blocks, and decide: accepted, accepted with conditions, or blocked until fixed. If a requirement cannot be met, change the design or the risk response, as SSDF PW.2.1 suggests, and record any accepted risk with an owner and a date to revisit.

7. Feed recurring findings back

   When the same finding appears in several reviews, fix its cause: update the pattern catalog, the reference architecture or the requirement baseline (Security requirements), so the next design starts from the corrected version. OWASP SAMM describes this at its highest Architecture Assessment level.

Common mistakes

• Reviewing after the code is written. Design findings then become rework, or risks accepted because the release date is close.
• Letting the designer review their own design. Their assumptions are the blind spots the review exists to catch.
• Reviewing slides instead of the data flow. Without boundaries and identity sources, nobody can see who chooses each tenant or object ID.
• Leaving findings in meeting notes. Untracked findings are not fixed before the affected part is built, which is the point of the review.
• Reviewing only the main path. Support access, tenant switching, retries, queued jobs and error handling are where designs often break.

Threat model, design review or code review?

Three checks at different moments. Each one answers a question the others cannot.

Tools and guides

• Workflow: Review a design
• Review tenant boundaries before implementation

  Trace tenant identity through requests, data stores, caches, jobs, and administration, then turn plausible isolation failures into tests.

• Choose a threat modeling method and turn its findings into tests

  Use the four-question frame to scope a design, pick STRIDE, attack trees, LINDDUN or PASTA by the question you need answered, and leave behind threat records and abuse-case tests the team can run.

• Secure design patterns: a catalogue for insecure-design (A06)

  A catalogue of reusable secure-design patterns, grouped by concern, each with when to use it, a short example and the failure it prevents: choke-point authorization, capability tokens, parse-don't-validate, safe-by-default APIs, tenant scoping, fail-closed, idempotency, and more.

• Authorization models: RBAC, ABAC, ReBAC and policy as code you can test

  Translate roles, attributes and relationships into explicit subject-action-resource decisions, prevent broken object level authorization (BOLA), and verify ownership and tenant boundaries with tests.

Standards

NIST SSDF 1.1

PW.2 Review the Software Design to Verify Compliance with Security Requirements and Risk Information

OWASP SAMM 2

Architecture Assessment

Sources

1. NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.
2. OWASP SAMM: Architecture Assessment
3. OWASP SAMM: Architecture Assessment, stream A (Architecture Validation)
4. OWASP SAMM: Architecture Assessment, stream B (Architecture Mitigation)
5. OWASP Threat Modeling Cheat Sheet