/nw-security-by-design
Security design principles, STRIDE threat modeling, OWASP Top 10 architectural mitigations, and secure patterns. Load when designing systems or reviewing architecture for security.
Claude Code
$ npx -y skills add nWave-ai/nWave --skill nw-security-by-design --agent claude-code
Codex
$ npx skills add nWave-ai/nWave --skill nw-security-by-design -a codex -y
Cursor
$ npx skills add nWave-ai/nWave --skill nw-security-by-design -a cursor -y
Gemini CLI
$ npx skills add nWave-ai/nWave --skill nw-security-by-design -a gemini-cli -y
GitHub Copilot
$ npx skills add nWave-ai/nWave --skill nw-security-by-design -a github-copilot -y
OpenCode
$ npx skills add nWave-ai/nWave --skill nw-security-by-design -a opencode -y
Windsurf
$ npx skills add nWave-ai/nWave --skill nw-security-by-design -a windsurf -y
SKILL.md
nw-security-by-design.SKILL.mdname: nw-security-by-design
description: Security design principles, STRIDE threat modeling, OWASP Top 10 architectural mitigations, and secure patterns. Load when designing systems or reviewing architecture for security.
user-invocable: false
disable-model-invocation: true
Security by Design
OWASP Security Design Principles
Apply these during design -- retrofitting security is 10-100x more expensive.
| # | Principle | Architect Action | |---|-----------|-----------------| | 1 | Security by Design | Include security requirements in architecture documents | | 2 | Security by Default | Ship restrictive defaults; require explicit opt-in for relaxed settings | | 3 | Defense in Depth | Layer controls: WAF + input validation + output encoding + parameterized queries | | 4 | Fail Secure | Deny access on error; closed-by-default network policies | | 5 | Least Privilege | Scoped service accounts; time-limited tokens; minimum permissions | | 6 | Compartmentalize | Network segmentation; separate databases per trust level | | 7 | Separation of Duties | Separate deployment approval from code authorship | | 8 | Economy of Mechanism | Minimize attack surface; simple, auditable security code | | 9 | Complete Mediation | Check authorization on every request; no cached auth decisions | | 10 | Open Design | Use published, peer-reviewed algorithms; no security-through-obscurity | | 11 | Least Common Mechanism | Separate admin and user interfaces | | 12 | Psychological Acceptability | Make the secure path the easy path; minimize user friction |
STRIDE Threat Modeling
Apply STRIDE to every component in a Data Flow Diagram (DFD). Four questions drive every session: 1. What are we working on? (system model) 2. What can go wrong? (threat identification) 3. What are we going to do about it? (mitigation) 4. Did we do a good enough job? (review)
STRIDE Reference
| Threat | Violated Property | Architectural Mitigation | |--------|-------------------|--------------------------| | **Spoofing** | Authentication | MFA, mutual TLS, certificate pinning, OAuth2+PKCE | | **Tampering** | Integrity | Input validation, HMAC, parameterized queries, immutable infra | | **Repudiation** | Non-repudiation | Tamper-evident logging (append-only), digital signatures, SIEM | | **Info Disclosure** | Confidentiality | Encryption at rest+transit, least privilege, generic error messages | | **Denial of Service** | Availability | Rate limiting, circuit breakers, auto-scaling, query complexity limits | | **Elevation of Privilege** | Authorization | Least privilege, RBAC/ABAC, signed tokens verified server-side |
STRIDE per DFD Element
| DFD Element | Most Relevant Threats | |-------------|----------------------| | External Entity | Spoofing | | Process | All six STRIDE threats | | Data Store | Tampering, Info Disclosure, Repudiation, DoS | | Data Flow | Tampering, Info Disclosure, DoS | | Trust Boundary | Spoofing, Tampering, Elevation of Privilege |
Risk Response Options
| Response | When | Example | |----------|------|---------| | Mitigate | Probable and impactful; controls feasible | Add MFA for spoofing on admin login | | Eliminate | Remove feature/component entirely | Remove unused admin API endpoint | | Transfer | Better managed by another party | Use managed IdP (Auth0, Cognito) | | Accept | Low risk; mitigation cost exceeds impact | Accept DoS risk on internal status page |
OWASP Top 10 -- Architectural Prevention
Focus on what the architect decides at design time, not implementation details.
A01: Broken Access Control (61% of breaches)
- Deny by default -- no endpoint open unless explicitly granted
- Centralized authorization service (OPA, Casbin, Cedar), not scattered checks
- Resource-level ownership -- queries scoped to authenticated user
- ABAC over simple RBAC for complex multi-tenant systems
- CORS with explicit origin allowlists -- never wildcards with credentials
A02/A05: Security Misconfiguration (rose to #2 in 2025)
- Infrastructure as Code with security scanning (tfsec, checkov) in CI/CD
- Hardened base images -- minimal containers with security baked in
- Configuration drift detection with automated alerting
- Environment parity -- same hardening across dev/staging/prod
A03: Injection (SQL #2 in CWE Top 25 2025)
- Parameterized queries everywhere -- reject PRs with string concatenation in SQL
- Treat ALL database-sourced data as potentially tainted (second-order injection)
- Allowlisting for dynamic query elements (table names, sort columns)
- Template sandboxing -- user input as DATA, never as template source
A04: Insecure Design (new in 2021)
- Mandate STRIDE analysis as gate for architecture reviews
- Abuse cases alongside every user story ("As an attacker, I want to...")
- State machines with explicit transitions for business logic
- Rate limiting built into architecture from day one
A06/Supply Chain (expanded in 2025)
- SCA scanning on every commit (Snyk, Dependabot)
- SBOM generation as build artifact
- Private package registry; block direct public pulls in production builds
- Lock files committed with integrity hash verification
A07: Authentication Failures
- Centralized IdP (Keycloak, Auth0, Cognito) -- no custom auth per service
- MFA required for sensitive data access and admin functions
- Progressive delays on failed attempts (exponential backoff, not permanent lockout)
- Session ID regeneration on every authentication state change
Secure Architecture Patterns
Zero Trust
Core: "Never trust, always verify" -- no implicit trust from network location.
| Component | Implementation | |-----------|---------------| | Identity verification | OAuth2/OIDC for users; mTLS for services | | Transport security | mTLS everywhere; service mesh (Istio, Linkerd) | | Micro-segmentation | Network policies limiting service-to-service | | Continuous verification | Re-authenticate and re-authorize every request | | Least privilege access | Sc
Read more
name: nw-security-by-design description: Security design principles, STRIDE threat modeling, OWASP Top 10 architectural mitigations, and secure patterns. Load when designing systems or reviewing architecture for security. user-invocable: false disable-model-invocation: true
Security by Design
OWASP Security Design Principles
Apply these during design -- retrofitting security is 10-100x more expensive.
| # | Principle | Architect Action | |---|-----------|-----------------| | 1 | Security by Design | Include security requirements in architecture documents | | 2 | Security by Default | Ship restrictive defaults; require explicit opt-in for relaxed settings | | 3 | Defense in Depth | Layer controls: WAF + input validation + output encoding + parameterized queries | | 4 | Fail Secure | Deny access on error; closed-by-default network policies | | 5 | Least Privilege | Scoped service accounts; time-limited tokens; minimum permissions | | 6 | Compartmentalize | Network segmentation; separate databases per trust level | | 7 | Separation of Duties | Separate deployment approval from code authorship | | 8 | Economy of Mechanism | Minimize attack surface; simple, auditable security code | | 9 | Complete Mediation | Check authorization on every request; no cached auth decisions | | 10 | Open Design | Use published, peer-reviewed algorithms; no security-through-obscurity | | 11 | Least Common Mechanism | Separate admin and user interfaces | | 12 | Psychological Acceptability | Make the secure path the easy path; minimize user friction |
STRIDE Threat Modeling
Apply STRIDE to every component in a Data Flow Diagram (DFD). Four questions drive every session: 1. What are we working on? (system model) 2. What can go wrong? (threat identification) 3. What are we going to do about it? (mitigation) 4. Did we do a good enough job? (review)
STRIDE Reference
| Threat | Violated Property | Architectural Mitigation | |--------|-------------------|--------------------------| | **Spoofing** | Authentication | MFA, mutual TLS, certificate pinning, OAuth2+PKCE | | **Tampering** | Integrity | Input validation, HMAC, parameterized queries, immutable infra | | **Repudiation** | Non-repudiation | Tamper-evident logging (append-only), digital signatures, SIEM | | **Info Disclosure** | Confidentiality | Encryption at rest+transit, least privilege, generic error messages | | **Denial of Service** | Availability | Rate limiting, circuit breakers, auto-scaling, query complexity limits | | **Elevation of Privilege** | Authorization | Least privilege, RBAC/ABAC, signed tokens verified server-side |
STRIDE per DFD Element
| DFD Element | Most Relevant Threats | |-------------|----------------------| | External Entity | Spoofing | | Process | All six STRIDE threats | | Data Store | Tampering, Info Disclosure, Repudiation, DoS | | Data Flow | Tampering, Info Disclosure, DoS | | Trust Boundary | Spoofing, Tampering, Elevation of Privilege |
Risk Response Options
| Response | When | Example | |----------|------|---------| | Mitigate | Probable and impactful; controls feasible | Add MFA for spoofing on admin login | | Eliminate | Remove feature/component entirely | Remove unused admin API endpoint | | Transfer | Better managed by another party | Use managed IdP (Auth0, Cognito) | | Accept | Low risk; mitigation cost exceeds impact | Accept DoS risk on internal status page |
OWASP Top 10 -- Architectural Prevention
Focus on what the architect decides at design time, not implementation details.
A01: Broken Access Control (61% of breaches)
- Deny by default -- no endpoint open unless explicitly granted
- Centralized authorization service (OPA, Casbin, Cedar), not scattered checks
- Resource-level ownership -- queries scoped to authenticated user
- ABAC over simple RBAC for complex multi-tenant systems
- CORS with explicit origin allowlists -- never wildcards with credentials
A02/A05: Security Misconfiguration (rose to #2 in 2025)
- Infrastructure as Code with security scanning (tfsec, checkov) in CI/CD
- Hardened base images -- minimal containers with security baked in
- Configuration drift detection with automated alerting
- Environment parity -- same hardening across dev/staging/prod
A03: Injection (SQL #2 in CWE Top 25 2025)
- Parameterized queries everywhere -- reject PRs with string concatenation in SQL
- Treat ALL database-sourced data as potentially tainted (second-order injection)
- Allowlisting for dynamic query elements (table names, sort columns)
- Template sandboxing -- user input as DATA, never as template source
A04: Insecure Design (new in 2021)
- Mandate STRIDE analysis as gate for architecture reviews
- Abuse cases alongside every user story ("As an attacker, I want to...")
- State machines with explicit transitions for business logic
- Rate limiting built into architecture from day one
A06/Supply Chain (expanded in 2025)
- SCA scanning on every commit (Snyk, Dependabot)
- SBOM generation as build artifact
- Private package registry; block direct public pulls in production builds
- Lock files committed with integrity hash verification
A07: Authentication Failures
- Centralized IdP (Keycloak, Auth0, Cognito) -- no custom auth per service
- MFA required for sensitive data access and admin functions
- Progressive delays on failed attempts (exponential backoff, not permanent lockout)
- Session ID regeneration on every authentication state change
Secure Architecture Patterns
Zero Trust
Core: "Never trust, always verify" -- no implicit trust from network location.
| Component | Implementation | |-----------|---------------| | Identity verification | OAuth2/OIDC for users; mTLS for services | | Transport security | mTLS everywhere; service mesh (Istio, Linkerd) | | Micro-segmentation | Network policies limiting service-to-service | | Continuous verification | Re-authenticate and re-authorize every request | | Least privilege access | Sc
AI agents that guide you from idea to working code, with human judgment at every gate. nWave runs inside Claude Code. It breaks feature delivery into seven waves (discover, diverge, discuss, design, devops, distill, deliver).
Other skills on nwave.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about nw-security-by-design.
- Which coding agents can use nw-security-by-design?
- nw-security-by-design installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

