/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.
$ npx -y skills add nWave-ai/nWave --skill nw-security-by-design --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/nw-security-by-design
Context preview
The summary Claude sees to decide when to auto-load this skill.
Security design principles, STRIDE threat modeling, OWASP Top 10 architectural mitigations, and secure patterns. Load when designing systems or reviewing architecture for security.
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).
Repo: nWave-ai/nWave
Other skills on nwave.
- /nw-ab-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Open skill - /nw-abr-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Open skill - /nw-ad-critique-dimensions
Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof
Open skill - /nw-agent-creation-workflow
Detailed 5-phase workflow for creating agents - from requirements analysis through validation and iterative refinement
Open skill - /nw-agent-testing
5-layer testing approach for agent validation including adversarial testing, security validation, and prompt injection resistance
Open skill - /nw-architectural-styles-tradeoffs
Architectural style selection decision matrices, trade-off analysis, structural enforcement rules, and combination patterns. Load when choosing or evaluating architecture styles.
Open skill

