Skip to content
Development
Skill

/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.

From plugin
nwave
591200 skills34 agents27 commands
Install
$ npx -y skills add nWave-ai/nWave --skill nw-security-by-design --agent claude-code

How 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.md
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

Read more
Ships withnwave

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).

Get the whole plugin