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.

322 stars

Best use case

nw-security-by-design is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Security design principles, STRIDE threat modeling, OWASP Top 10 architectural mitigations, and secure patterns. Load when designing systems or reviewing architecture for security.

Teams using nw-security-by-design should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/nw-security-by-design/SKILL.md --create-dirs "https://raw.githubusercontent.com/nWave-ai/nWave/main/nWave/skills/nw-security-by-design/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/nw-security-by-design/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How nw-security-by-design Compares

Feature / Agentnw-security-by-designStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Security design principles, STRIDE threat modeling, OWASP Top 10 architectural mitigations, and secure patterns. Load when designing systems or reviewing architecture for security.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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 | Scoped tokens; just-in-time access |

### Input Validation Pipeline

```
User Input
  -> Validation (allowlist, type, length, format)
    -> Business Logic (parameterized queries, ORM)
      -> Output Encoding (context-aware: HTML, JS, URL, CSS)
        -> Client
```

Key: input validation is complementary, not primary defense. Output encoding prevents XSS. Parameterized queries prevent SQLi. Validation adds defense in depth.

### Secrets Management

| Pattern | Implementation |
|---------|---------------|
| Centralized vault | HashiCorp Vault, AWS Secrets Manager, Azure Key Vault |
| Sidecar injection | Vault agent injects secrets into pods at runtime |
| Encrypted in repo | SOPS + KMS for GitOps workflows |
| Pre-commit scanning | gitleaks or TruffleHog blocks secrets before they reach git |

Rules: never in source code | never in container images | rotate automatically | separate per environment | audit all access.

### Required HTTP Security Headers

| Header | Value | Purpose |
|--------|-------|---------|
| Content-Security-Policy | Strict nonce-based | Prevent XSS |
| Strict-Transport-Security | `max-age=63072000; includeSubDomains; preload` | Force HTTPS |
| X-Content-Type-Options | `nosniff` | Prevent MIME sniffing |
| X-Frame-Options | `DENY` or `SAMEORIGIN` | Prevent clickjacking |
| Referrer-Policy | `strict-origin-when-cross-origin` | Control referrer |
| Permissions-Policy | Feature-specific | Limit browser APIs |

## Security Testing in CI/CD

| Type | Tests | Pipeline Stage | Tools |
|------|-------|---------------|-------|
| SAST | Source code vulnerabilities | Every commit/PR | Semgrep, CodeQL, SonarQube |
| SCA | Dependency CVEs | Build stage | Snyk, Dependabot, Trivy |
| DAST | Running application | Staging | OWASP ZAP, Burp Suite |
| Secrets | Leaked credentials | Pre-commit + CI | gitleaks, TruffleHog |

Strategy: SAST pre-commit (fast) -> SCA at build -> container scan -> DAST on staging -> block on critical/high findings.

## API Security Checklist (OWASP API Top 10)

| # | Threat | Architect Decision |
|---|--------|--------------------|
| API1 | BOLA (~40% of API attacks) | Object-level authorization in service layer, not just routes |
| API4 | Unrestricted resource consumption | Rate limiting per-object, not just per-endpoint |
| API5 | BFLA | Separate admin and user API surfaces |
| API6 | Sensitive business flow abuse | State machine enforcement, idempotency keys |
| API9 | Improper inventory management | API versioning with sunset policies; deprecate old versions |
| API10 | Unsafe API consumption | Never trust third-party API responses; validate and sanitize |

### GraphQL-Specific

- Disable introspection in production
- Set maximum query depth (10 levels) and complexity limits
- Limit batch size; exclude sensitive operations from batching
- Field-level authorization in resolvers

## Defensive Coding Patterns (Cross-Reference for Crafters)

| Risk | Vulnerable Pattern | Secure Alternative |
|------|-------------------|-------------------|
| SQL Injection | `f"SELECT * FROM users WHERE name = '{name}'"` | Parameterized: `cursor.execute("... WHERE name = %s", (name,))` |
| Deserialization | `pickle.loads(untrusted)` | `json.loads(untrusted)` or Pydantic schema validation |
| Command Injection | `os.system(f"cmd {input}")` | `subprocess.run(["cmd", input], shell=False)` |
| SSTI | `Template(user_input)` | `env.from_string(trusted).render(data=user_input)` |
| Mass Assignment | `User(**request.json())` | DTO with explicit fields, server-set for sensitive |
| TOCTOU Race | Read-check-write in separate steps | Atomic conditional update (`UPDATE ... WHERE condition`) |
| Prototype Pollution (JS) | `Object.assign(target, untrusted)` | `Map`, null-prototype objects, strict schema validation |

Related Skills

nw-ux-emotional-design

322
from nWave-ai/nWave

Emotional design and delight patterns for product owners. Load when designing onboarding flows, empty states, first-run experiences, or evaluating the emotional quality of an interface.

nw-test-design-mandates

322
from nWave-ai/nWave

Four design mandates for acceptance tests - hexagonal boundary enforcement, business language abstraction, user journey completeness, walking skeleton strategy, and pure function extraction

nw-security-and-governance

322
from nWave-ai/nWave

Database security (encryption, access control, injection prevention), data governance (lineage, quality, MDM), and compliance frameworks (GDPR, CCPA, HIPAA)

nw-fp-usable-design

322
from nWave-ai/nWave

Naming conventions, API ergonomics, and usability patterns for functional code

nw-fp-algebra-driven-design

322
from nWave-ai/nWave

Algebra-driven API design with monoids, semigroups, and interpreters via algebraic equations

nw-domain-driven-design

322
from nWave-ai/nWave

Strategic and tactical DDD patterns, bounded context discovery, context mapping, aggregate design rules, and decision frameworks for when to apply DDD

nw-design

322
from nWave-ai/nWave

Designs system architecture with C4 diagrams and technology selection. Routes to the right architect based on design scope (system, domain, application, or full stack). Two interaction modes: guide (collaborative Q&A) or propose (architect presents options with trade-offs).

nw-design-patterns

322
from nWave-ai/nWave

7 agentic design patterns with decision tree for choosing the right pattern for each agent type

nw-design-methodology

322
from nWave-ai/nWave

Apple LeanUX++ design workflow, journey schema, emotional arc patterns, and CLI UX patterns. Load when transitioning from discovery to visualization or when designing journey artifacts.

nw-command-design-patterns

322
from nWave-ai/nWave

Best practices for command definition files - size targets, declarative template, anti-patterns, and canonical examples based on research evidence

nw-ux-web-patterns

322
from nWave-ai/nWave

Web UI design patterns for product owners. Load when designing web application interfaces, writing web-specific acceptance criteria, or evaluating responsive designs.

nw-ux-tui-patterns

322
from nWave-ai/nWave

Terminal UI and CLI design patterns for product owners. Load when designing command-line tools, interactive terminal applications, or writing CLI-specific acceptance criteria.