| 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
- Architecture & trust boundaries — components, data flows, and where trust/
privilege changes. Build/ingest the picture with
security-diagramming:architecture-diagram / threat-model-dfd.
- Threats by design — run
threat-modeling:stride (or pasta) over the design
to enumerate threats per element and boundary crossing.
- 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.
- 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.
- 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).
- Trade-offs — weigh risk reduction against usability, performance, and cost;
recommend proportionate controls, not maximal ones.
Steps
- Establish context: purpose, data sensitivity, users, threat model, and constraints.
- Diagram the architecture and trust boundaries.
- Enumerate threats (
threat-modeling) and map existing/missing controls to them.
- Assess against secure-by-design principles; identify design-level weaknesses.
- 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.
