security-design-review

name	security-design-review
description	Review a system or architecture design for security — trust boundaries, control selection, secure-by-design principles, defense-in-depth, and security requirements — and produce prioritized design recommendations. Use when assessing or shaping an architecture/design (not testing a running system).

Goal

A design-level security assessment: where the design is weak by construction, which controls are missing or misplaced, and the prioritized changes — caught at design time, before it's built.

What to review

1. Architecture & trust boundaries — components, data flows, and where trust/ privilege changes. Build/ingest the picture with security-diagramming:architecture-diagram / threat-model-dfd.
2. Threats by design — run threat-modeling:stride (or pasta) over the design to enumerate threats per element and boundary crossing.
3. Control selection — are the right controls present at the right layers (authn/authz, encryption, segmentation, input handling, logging, key/secret management)? Map controls to the threats they address; find gaps and redundancies.
4. Secure-by-design principles — least privilege, defense-in-depth, fail-safe defaults, complete mediation, minimize attack surface, secure defaults, separation of duties, no security-by-obscurity.
5. Security requirements — derive the non-negotiable requirements the build must meet (and how they'll be verified later — ties to the relevant domain plugin's testing skills).
6. Trade-offs — weigh risk reduction against usability, performance, and cost; recommend proportionate controls, not maximal ones.

Steps

1. Establish context: purpose, data sensitivity, users, threat model, and constraints.
2. Diagram the architecture and trust boundaries.
3. Enumerate threats (threat-modeling) and map existing/missing controls to them.
4. Assess against secure-by-design principles; identify design-level weaknesses.
5. Recommend prioritized changes and the security requirements for the build.

Output

A design review: architecture diagram · threat→control mapping · design weaknesses · prioritized recommendations · security requirements (with verification method). Use security-reporting; rank with threat-modeling:risk-rank.

Notes

Fixing a design flaw on paper is far cheaper than after it ships — focus on structural weaknesses (missing boundaries, wrong trust assumptions, absent controls), not implementation bugs (those are the domain plugins' job). Recommend proportionate, layered controls and make the trade-offs explicit for the decision-maker.