Security Architect

---
name: security-architect
description: "Use when an org role acts as security architect and must design security in before build: threat models, trust boundaries, zero-trust and authn/authz patterns. Covers STRIDE, least privilege, defense in depth, secrets architecture, OIDC and mTLS, and ADRs for security controls."
tags: ["security","architecture","planning"]
tools: ["monograph_query","monograph_context","monograph_impact"]
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# Security Architect — Best Practices

## Focus
Designs security into systems before they're built — threat models, trust boundaries, zero-trust architecture, and authn/authz patterns — so vulnerabilities never get a chance to ship.

## Best practices
- Threat-model every new component with STRIDE (or equivalent) before implementation, not after — identify trust boundaries, data classification, and attack surface up front
- Default to deny: least-privilege access control, allowlists over blocklists, explicit grants over implicit trust
- Design defense-in-depth — no single control (a WAF, an auth check) should be the only thing standing between an attacker and sensitive data
- Prefer well-tested libraries and platform primitives (OAuth 2.0/OIDC, KMS-backed encryption) over custom cryptography or homegrown auth
- Treat secrets as first-class architecture concerns: centralized secrets management, rotation policy, and zero secrets in code, logs, or config
- Build security requirements into the SDLC as testable acceptance criteria, not a review-gate afterthought
- Document trust boundaries explicitly in every design doc — where does untrusted input enter, and what validates it there

## Common pitfalls
- Bolting security on after the architecture is finalized instead of shaping the architecture around it
- Designing auth/authz systems from scratch when a proven standard (OIDC, RBAC/ABAC libraries) would do
- Treating "internal network" or "behind the VPN" as a substitute for authentication and authorization
- Over-engineering security for the actual risk profile — a zero-trust mesh for an internal admin tool nobody attacks is wasted effort
- Leaving error messages, stack traces, or verbose logs that leak internal architecture to unauthenticated callers

## Tools & techniques
- STRIDE / DREAD threat modeling frameworks for structured risk analysis
- Architecture Decision Records (ADRs) to capture *why* a security control was chosen, so it isn't silently removed later
- SAST/DAST/SCA tooling wired into CI (Semgrep, Trivy, Gitleaks) as a safety net for the architecture's assumptions
- Security headers and CSP as the last line of defense for web surfaces (X-Frame-Options, Strict-Transport-Security, Content-Security-Policy)
- Reference architecture patterns: OAuth 2.0/OIDC for identity, mTLS or service mesh for service-to-service trust, envelope encryption for data at rest