security-design

Security design codifies trust boundaries, threat models, and required controls at each architectural layer. It defines assets, abuse paths, and concrete controls including authentication, authorization, secret handling, and logging before code implementation.

Create a threat model by defining assets, trust boundaries, and abuse paths to preempt data leakage. Enumerate concrete controls per boundary including authentication, authorization, secret handling, and logging to enable auditable security design decisions.

Define trust boundaries during architecture-reviewed security integrations for brownfield or new systems. It is required when systems have sensitive data paths or brownfield coexistence to guide architecture decisions and enable auditable security reviews.

Yes, security design applies to systems with brownfield coexistence. Use it during architecture-reviewed security integrations to define trust boundaries, enumerate controls, and ensure auditable security decisions for existing systems.

Architecture security review requires architecture-doc and api-contract as inputs. The prerequisite is an existing system-design, and the process outputs a threat-model along with governance signals like quality_gate and roles for auditable decisions.

Defining security boundaries before coding preempts data leakage and unauthorized access. Security design sits upstream of audit, ensuring defenses are architected into the system rather than inspecting code later, enabling auditable architecture decisions.