/security-review

name: security-review
description: "OWASP secure design review for code and architecture. Checks input validation, authentication, authorization, data protection."
metadata:
  instruction_budget: "42"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

Security Review

Language-agnostic security review based on OWASP Secure by Design.

Step 0: Scope the review to what the product holds and does (v0.271.0)

**Record the scope first, then apply only the sections it calls for.** Every product has threats, but not every product has a login, code, or personal data. Founder, 2026-09-26: "2fa and so on might not be applicable for all products." A bookkeeping service delivered by hand was reviewed against this web checklist (CORS, SQL parameters, security headers, multi-factor login), most of which has nothing to act on there. Write in `.claude/canvas/threat-model.yml`, under its own key (`scope` stays the threat model's own sentence on what is being modelled; 0.271.0 reused that name and broke every threat model that had one):

security_scope:
  runs_code: true | false          # software the product runs (a web app, an API, a script)
  accounts: true | false           # people log in to something the product provides
  personal_data: "none" | what     # e.g. "client bank exports and receipts", "email addresses"
  money: true | false              # the product takes or moves payments
  reach: who can get at it         # e.g. "three named clients", "anyone with the link"

Then apply, and name each section as applied or `n/a: <reason>` in the decision-log entry:

| Section | Applies when | |---|---| | OWASP web categories below (A01-A10b) | `runs_code` | | Authentication items (A07: sessions, passwords, multi-factor) | `accounts` | | Data protection items (A02, and Documents and data handled by people) | `personal_data` is not "none" | | Payment integrity (who can change amounts, refunds, receipts) | `money` | | OWASP LLM Top 10 | the product runs a model (`ai_tool`) | | OWASP Agentic Skills Top 10 | the product ships agent skills, plugins, hooks or MCP servers |

Controls follow the data and the reach: multi-factor login where accounts guard sensitive data, encryption where personal data is stored or sent electronically, not as defaults for every product. A section that does not apply is recorded as `n/a` with its reason, never silently skipped, so a later reader sees it was considered. **The threat model is never `n/a`**: a service with nothing digital still has threats (a mis-sent document, a lost folder, a wrong person asking for a client's figures).

Documents and data handled by people (services, courses, publications)

• [ ] Where client or learner data is kept, and who can open it
• [ ] How documents move between people (the channel, and what never goes by it)
• [ ] What happens when a document is mis-sent, lost or seen by the wrong person
• [ ] How long it is kept, and how it is removed
• [ ] Who else handles it (assistants, subcontractors, providers) and on what terms

Checklist (OWASP Top 10:2025, applies when `runs_code`)

*Updated to OWASP Top 10:2025 (released January 2025). Previous 2021 edition had different groupings.*

A01:2025 — Broken Access Control

• [ ] Least privilege enforced (users get minimum permissions needed)
• [ ] Authorization checked on EVERY request (not just the first)
• [ ] CORS restrictive (not `*`)
• [ ] Directory listing disabled
• [ ] Rate limiting on API/controller access

A02:2025 — Cryptographic Failures

• [ ] Data encrypted at rest and in transit (TLS 1.2+)
• [ ] No secrets in code, logs, or error messages
• [ ] PII identified and classified in threat model
• [ ] Passwords hashed with bcrypt/argon2 (never MD5/SHA1)
• [ ] Cryptographic algorithms current (no deprecated ciphers)

A03:2025 — Injection

• [ ] All user input validated (type, length, range, format)
• [ ] Parameterized queries for ALL data access (never string concatenation)
• [ ] Input allowlisting preferred over denylisting
• [ ] Output encoded based on context (HTML, JS, URL, CSS — covers XSS)
• [ ] Content Security Policy configured

A03b:2025 — Software Supply Chain Failures *(new in 2025)*

• [ ] SBOM (Software Bill of Materials) maintained for critical dependencies
• [ ] Build integrity verified (reproducible builds, signed artifacts)
• [ ] Dependency provenance checked (not just version, but source authenticity)
• [ ] Transitive dependencies audited (not just direct)
• [ ] Lock files committed and verified

A04:2025 — Insecure Design

• [ ] Threat modeling performed (STRIDE — see /mycelium:threat-model)
• [ ] Secure design patterns used (defense in depth, fail secure)
• [ ] Business logic abuse cases considered
• [ ] Security requirements defined alongside functional requirements

A05:2025 — Security Misconfiguration

• [ ] Default credentials changed
• [ ] Unnecessary features/ports disabled
• [ ] Security headers set (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
• [ ] Error handling does not expose stack traces

A06:2025 — Vulnerable and Outdated Components

• [ ] Dependency audit run (no known critical vulnerabilities)
• [ ] Dependencies pinned to specific versions
• [ ] Automated scanning in CI
• [ ] Unused dependencies removed

A07:2025 — Identification and Authentication Failures

• [ ] Session IDs regenerated on login
• [ ] Multi-factor authentication available for sensitive operations
• [ ] Credential stuffing protections (rate limiting, account lockout)
• [ ] Password strength requirements enforced

A08:2025 — Software and Data Integrity Failures

• [ ] CI/CD pipeline integrity verified (no unsigned code execution)
• [ ] Deserialization inputs validated
• [