@baselane/packs 0.1.4 → 0.1.5

package/packs/security-review/pack.json

@@ -1,13 +1,17 @@
 {
   "$schema": "https://baselane.dev/schema/workflow-pack-v1.json",
   "id": "security-review",
-  "version": "2.0.0",
+  "version": "3.0.0",
   "title": "Security review",
-  "summary": "A 4-layer pre-deploy security audit (secrets, authentication, input validation, data access) with per-layer prompts and a scan toolkit, a reviewer role, a /security-scan diff check, a /security-audit pre-deploy pass, a pre-ship Stop-hook reminder, and baseline security rules for every endpoint — flags real vulnerabilities with severity and file:line, not theater.",
+  "summary": "Comprehensive OWASP Top 10 + secrets/input/auth/XSS/CSRF/rate-limiting/logging/dependency/cloud-infra security review discipline, a 4-layer pre-deploy audit, a full-checklist skill with cloud-infra reference, an AI-harness config scan skill, a reviewer agent, full-audit and diff-scoped scan commands, and a portable secret-leak guard hook — flags real vulnerabilities with severity and file:line, not theater.",
   "scope": "repo",
-  "attribution": { "source": "affaan-m/ECC", "url": "https://github.com/affaan-m/ECC", "license": "MIT" },
+  "attribution": {
+    "source": "affaan-m/ECC (Everything Claude Code)",
+    "url": "https://github.com/affaan-m/ECC",
+    "license": "MIT"
+  },
   "context": {
-    "markdown": "## Security review discipline\n\nRun this against any code that handles user input, authentication, API endpoints, or sensitive data — before it reaches production.\n\n### Security rules (apply to every endpoint, always)\n\n- Never hardcode secrets — read them from environment variables (or a secret manager) and fail fast at startup if a required one is missing.\n- Use parameterized queries — never build a query by concatenating a user value into a string.\n- Every endpoint verifies authentication and authorization server-side; the client hiding a button is not access control.\n- Every data query filters by the authenticated user's own id (or explicitly checks an admin role) — never trust a client-supplied id.\n- Validate all input server-side against a schema — client-side validation alone is not validation.\n- Return generic error messages to the client; log full detail server-side only.\n- Rate-limit authentication endpoints.\n- Enable row-level security (RLS) by default on any database that supports it.\n- Set secure cookie flags — `httpOnly`, `secure`, `sameSite` — on every session cookie.\n\n### Checklist\n\n- **Injection** — Validate every external or untrusted input at the boundary before it reaches business logic; fail fast with a clear message. Are queries parameterized? Is user input ever concatenated into a query, shell command, or template string?\n- **Authorization** — Is every route/mutation checked for auth, not just authentication? Is access scoped to the resource owner, not just \"logged in\"?\n- **Secrets** — Never hardcode secrets — read them from environment variables and fail fast at startup if a required one is missing. Any hardcoded API key, password, token, or connection string in source?\n- **Unsafe deserialization** — Is untrusted input ever passed to `eval`, a pickle/deserialize call, or a dynamic `require`/`import` without validation?\n- **SSRF** — Does the server ever fetch a URL supplied by the user? If so, is the destination allow-listed, not just \"looks like a URL\"?\n- **XSS** — Is user content ever rendered as raw HTML (`innerHTML`, `dangerouslySetInnerHTML`) without sanitization?\n- **Logging** — Do logs ever include a password, token, or full PII record?\n\n### Severity\n\nHardcoded secrets, injection, and auth bypass are CRITICAL — block merge. XSS and SSRF without an allow-list are HIGH. Missing rate limiting or verbose error messages are MEDIUM.\n\n### False positives to skip\n\n`.env.example` placeholders, clearly-marked test credentials, and public API keys meant to be public are not findings — verify context before flagging.\n"
+    "markdown": "## Security review discipline\n\nRun this against any code that handles user input, authentication, API endpoints, secrets, or sensitive data — before it reaches production. This pack merges baselane's own review discipline with the security material from ECC (Everything Claude Code, MIT).\n\n### Core security rules (apply to every endpoint, always)\n\n- Never hardcode secrets — read them from environment variables (or a secret manager) and fail fast at startup if a required one is missing.\n- Use parameterized queries — never build a query by concatenating a user value into a string.\n- Every endpoint verifies authentication and authorization server-side; the client hiding a button is not access control.\n- Every data query filters by the authenticated user's own id (or explicitly checks an admin role) — never trust a client-supplied id.\n- Validate all input server-side against a schema — client-side validation alone is not validation.\n- Return generic error messages to the client; log full detail server-side only.\n- Rate-limit authentication endpoints and other expensive operations.\n- Enable row-level security (RLS) by default on any database that supports it.\n- Set secure cookie flags — `httpOnly`, `secure`, `sameSite` — on every session cookie.\n- Keep dependencies current and act on `npm audit` / `pip-audit` findings.\n\n### Mandatory checks before ANY commit\n\n- [ ] No hardcoded secrets (API keys, passwords, tokens, connection strings)\n- [ ] All user inputs validated server-side\n- [ ] SQL injection prevention (parameterized queries only)\n- [ ] XSS prevention (sanitized HTML, CSP configured)\n- [ ] CSRF protection enabled on state-changing routes\n- [ ] Authentication/authorization verified on every route\n- [ ] Rate limiting on all public endpoints\n- [ ] Error messages don't leak sensitive data (stack traces, internals)\n\n### Severity\n\nHardcoded secrets, injection, and auth bypass are CRITICAL — block merge. XSS and SSRF without an allow-list, unrestricted shell access on Bash, and BOLA/IDOR gaps are HIGH. Missing rate limiting, verbose error messages, and silent error suppression are MEDIUM. Missing descriptions/hygiene items are INFO.\n\n### False positives to skip\n\n`.env.example` placeholders, clearly-marked test credentials, and public API keys meant to be public are not findings — verify context before flagging. SHA-256/MD5 used purely for checksums (not password storage) is not a finding.\n\n## OWASP Top 10 checklist\n\n1. **Injection** — Are queries parameterized? Is user input ever concatenated into a query, shell command, or template string? Are ORMs used safely?\n2. **Broken authentication** — Are passwords hashed with bcrypt/argon2? Are JWTs validated (signature, expiry, audience)? Are sessions secure?\n3. **Sensitive data exposure** — Is HTTPS enforced? Are secrets in env vars, never source? Is PII encrypted at rest? Are logs sanitized?\n4. **XXE** — Are XML parsers configured to disable external entities?\n5. **Broken access control** — Is auth checked on every route/mutation, not just authentication? Is CORS configured correctly (no wildcard with credentials)?\n6. **Security misconfiguration** — Are default credentials changed? Is debug mode off in prod? Are security headers set?\n7. **XSS** — Is output escaped? Is CSP set? Is the framework's auto-escaping relied on rather than bypassed?\n8. **Insecure deserialization** — Is untrusted input ever passed to `eval`, a pickle/deserialize call, or a dynamic `require`/`import` without validation?\n9. **Using components with known vulnerabilities** — Are dependencies current? Is `npm audit` / `pip-audit` clean?\n10. **Insufficient logging & monitoring** — Are security events (auth failures, admin actions) logged? Are alerts configured for anomalies?\n\nAlso check, beyond the classic 10:\n\n- **SSRF** — Does the server ever fetch a URL supplied by the user? If so, is the destination allow-listed, not just \"looks like a URL\"?\n- **Logging hygiene** — Do logs ever include a password, token, session id, or full PII record?\n\n### Code pattern reference\n\n| Pattern | Severity | Fix |\n| --- | --- | --- |\n| Hardcoded secrets | CRITICAL | Read from `process.env` / secret manager |\n| Shell command built from user input | CRITICAL | Use safe APIs or `execFile` with an argument array |\n| String-concatenated SQL | CRITICAL | Parameterized queries |\n| `innerHTML` / `dangerouslySetInnerHTML` on user content | HIGH | Sanitize (e.g. DOMPurify) or use `textContent` |\n| `fetch(userProvidedUrl)` with no allow-list | HIGH | Allow-list destination hosts |\n| Plaintext password comparison | CRITICAL | `bcrypt.compare()` / `argon2.verify()` |\n| No auth check on a route | CRITICAL | Add authentication + authorization middleware |\n| Balance/quantity check without a lock | CRITICAL | Use `FOR UPDATE` / an explicit transaction |\n| No rate limiting on an expensive or auth route | HIGH | Add rate limiting middleware |\n| Logging passwords/secrets/tokens | MEDIUM | Redact before logging |\n\n## Secrets management\n\n```typescript\n// FAIL — hardcoded\nconst apiKey = \"sk-proj-xxxxx\";\n\n// PASS — env var, fail fast if missing\nconst apiKey = process.env.OPENAI_API_KEY;\nif (!apiKey) throw new Error(\"OPENAI_API_KEY not configured\");\n```\n\n- [ ] No hardcoded API keys, tokens, or passwords\n- [ ] All secrets in environment variables or a secrets manager\n- [ ] `.env.local` (and equivalents) in `.gitignore`\n- [ ] No secrets in git history\n- [ ] Production secrets live in the hosting platform's secret store, not in a committed file\n\nIn cloud environments, prefer a managed secrets manager over a bare environment variable so access is audited and rotation is automatic:\n\n```typescript\n// PASS — cloud secrets manager, audited + rotatable\nimport { SecretsManager } from \"@aws-sdk/client-secrets-manager\";\nconst client = new SecretsManager({ region: \"us-east-1\" });\nconst secret = await client.getSecretValue({ SecretId: \"prod/api-key\" });\n```\n\n## Input validation\n\n```typescript\nimport { z } from \"zod\";\n\nconst CreateUserSchema = z.object({\n  email: z.string().email(),\n  name: z.string().min(1).max(100),\n  age: z.number().int().min(0).max(150),\n});\n\nexport async function createUser(input: unknown) {\n  const validated = CreateUserSchema.parse(input); // throws on bad shape\n  return await db.users.create(validated);\n}\n```\n\nFile uploads: enforce a size limit, an allow-listed MIME type, and a matching extension — all three, not just one.\n\n- [ ] All user inputs validated server-side with a schema\n- [ ] File uploads restricted (size, type, extension)\n- [ ] No direct use of user input in a query, shell command, or template string\n- [ ] Whitelist validation, not blacklist\n- [ ] Error messages don't leak internal detail\n\n## SQL injection prevention\n\n```typescript\n// FAIL — string-concatenated SQL\nconst query = `SELECT * FROM users WHERE email = '${userEmail}'`;\n\n// PASS — parameterized\nawait db.query(\"SELECT * FROM users WHERE email = $1\", [userEmail]);\n```\n\n- [ ] All database queries use parameterized queries or a query builder\n- [ ] No string concatenation in SQL\n- [ ] ORM/query builder used correctly (no raw-string escape hatches with user input)\n\n## Authentication & authorization\n\n```typescript\n// FAIL — token in localStorage (readable by any XSS)\nlocalStorage.setItem(\"token\", token);\n\n// PASS — httpOnly cookie\nres.setHeader(\"Set-Cookie\", `token=${token}; HttpOnly; Secure; SameSite=Strict; Max-Age=3600`);\n```\n\n```typescript\nexport async function deleteUser(userId: string, requesterId: string) {\n  const requester = await db.users.findUnique({ where: { id: requesterId } });\n  if (requester.role !== \"admin\") {\n    return NextResponse.json({ error: \"Unauthorized\" }, { status: 403 });\n  }\n  await db.users.delete({ where: { id: userId } });\n}\n```\n\nRow-level security, once available, is the backstop that catches an authorization check a developer forgot to write:\n\n```sql\nALTER TABLE users ENABLE ROW LEVEL SECURITY;\nCREATE POLICY \"Users view own data\" ON users FOR SELECT USING (auth.uid() = id);\nCREATE POLICY \"Users update own data\" ON users FOR UPDATE USING (auth.uid() = id);\n```\n\n- [ ] Tokens stored in httpOnly cookies, not `localStorage`\n- [ ] Authorization checked before every sensitive operation, scoped to resource owner (the BOLA/IDOR check — `GET /api/invoices/43` must 403/404 for anyone but the invoice's owner or an explicit admin)\n- [ ] Row-level security enabled where the database supports it\n- [ ] Session management is secure (rotation on privilege change, expiry enforced)\n\n## XSS prevention & CSP\n\n```typescript\nimport DOMPurify from \"isomorphic-dompurify\";\n\nfunction renderUserContent(html: string) {\n  const clean = DOMPurify.sanitize(html, { ALLOWED_TAGS: [\"b\", \"i\", \"em\", \"strong\", \"p\"], ALLOWED_ATTR: [] });\n  return <div dangerouslySetInnerHTML={{ __html: clean }} />;\n}\n```\n\nStart CSP strict and loosen only with a documented removal plan. Do not default to `'unsafe-inline'` or `'unsafe-eval'` — they neutralize much of CSP's protection and should be treated as temporary compatibility debt.\n\n```\nContent-Security-Policy:\n  default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none';\n  script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self';\n```\n\n- [ ] User-provided HTML sanitized before render\n- [ ] CSP headers configured (no blanket `unsafe-inline`/`unsafe-eval`)\n- [ ] No unvalidated dynamic content rendering\n- [ ] Framework's built-in escaping relied on rather than bypassed\n\n## CSRF\n\n```typescript\nexport async function POST(request: Request) {\n  const token = request.headers.get(\"X-CSRF-Token\");\n  if (!csrf.verify(token)) return NextResponse.json({ error: \"Invalid CSRF token\" }, { status: 403 });\n}\n```\n\n- [ ] CSRF tokens on state-changing operations\n- [ ] `SameSite=Strict` on session cookies\n- [ ] Double-submit cookie pattern where token-based CSRF isn't practical\n\n## Rate limiting\n\n```typescript\nconst limiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 100 });\napp.use(\"/api/\", limiter);\n\nconst searchLimiter = rateLimit({ windowMs: 60 * 1000, max: 10 }); // stricter for expensive ops\napp.use(\"/api/search\", searchLimiter);\n```\n\n- [ ] Rate limiting on all public API endpoints\n- [ ] Stricter limits on expensive operations (search, auth, sends)\n- [ ] Limits keyed by IP and, where authenticated, by user\n\n## Sensitive data exposure & logging\n\n```typescript\n// FAIL\nconsole.log(\"User login:\", { email, password });\ncatch (error) { return NextResponse.json({ error: error.message, stack: error.stack }, { status: 500 }); }\n\n// PASS\nconsole.log(\"User login:\", { email, userId });\ncatch (error) {\n  console.error(\"Internal error:\", error); // full detail server-side only\n  return NextResponse.json({ error: \"An error occurred. Please try again.\" }, { status: 500 });\n}\n```\n\n- [ ] No passwords, tokens, secrets, or full PII in logs\n- [ ] Error messages generic for the client; detail logged server-side only\n- [ ] No stack traces exposed to users\n\n## Dependency security\n\n```bash\nnpm audit --audit-level=high\nnpm audit fix\nnpm outdated\nnpm ci            # reproducible installs in CI, not `npm install`\n```\n\n- [ ] Dependencies current, `npm audit` clean at the chosen severity threshold\n- [ ] Lock files committed\n- [ ] Automated dependency update tooling enabled (e.g. Dependabot) where the platform supports it\n\n## Cloud & infrastructure security (summary)\n\nFull detail lives in the `cloud-infrastructure-security` reference alongside the `security-review` skill. Highlights to check on any deploy-touching change:\n\n- **IAM** — least privilege (no `*` actions on `*` resources), MFA on privileged accounts, service accounts use roles rather than long-lived keys.\n- **Network** — databases not publicly accessible, security groups scoped by CIDR and port, no `0.0.0.0/0` on anything but public HTTP(S).\n- **Secrets** — cloud secrets manager with rotation, not a bare env var for long-lived production credentials.\n- **CI/CD** — OIDC instead of long-lived cloud credentials, secret scanning and dependency audit as pipeline steps, branch protection + required review before merge.\n- **CDN/WAF** — security headers set (`X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy`), WAF/rate limiting enabled at the edge where available.\n- **Backups** — automated, retention meets the project's compliance bar, recovery tested rather than assumed.\n\n## Agent & harness security minimum bar\n\nThis project's own reviewer and the code it reviews increasingly run inside an AI coding harness, which is itself part of the attack surface (poisoned repo config, malicious hook definitions, prompt injection via fetched content or untrusted files). Treat these as review targets too, not just application code:\n\n- Agent/bot identities are separate from personal accounts (a dedicated bot user/email/token), never the developer's own credentials.\n- Credentials handed to an agent are short-lived and scoped to what the task needs — not org-wide, not long-lived.\n- Untrusted or foreign-content-heavy work (unfamiliar repos, email/PDF/webpage ingestion) runs in an isolated sandbox with no default network egress, not on the primary machine.\n- Harness permission config denies reads/writes to secret-bearing paths (`~/.ssh`, `~/.aws`, `.env*`) by default; a workflow that only needs to read a repo and run tests should not be able to read the home directory.\n- Anything read from outside the repo (fetched pages, tool output, PR/issue bodies, file attachments) is treated as untrusted content, not as instructions — a boundary a reviewer should flag if code blurs it (e.g. an agent tool that executes text from a fetched document).\n- The agent is not the final authority for unsandboxed shell execution, network egress, secret reads, or writes outside the workspace — a human-in-the-loop approval sits between the model and the action for all four.\n- Tool calls, approval decisions, files touched, and network attempts are logged somewhere a human can review after the fact.\n- Long-running/autonomous agent processes have an actual stop path (process-group kill, not just the parent process) and a heartbeat-based dead-man switch rather than relying on the process stopping itself.\n- Persistent agent memory stays narrow: no secrets in memory files, and memory from an untrusted run is reset or rotated rather than carried forward indefinitely.\n- Skills, hooks, MCP server configs, and agent descriptors pulled from outside the team are reviewed like any other supply-chain artifact before being trusted (unicode/zero-width-character checks, no unexplained outbound network commands, no silent permission escalation).\n\n## Pre-deployment security checklist\n\nBefore ANY production deployment:\n\n- [ ] Secrets: no hardcoded secrets, all in env vars or a secrets manager\n- [ ] Input validation: all user inputs validated server-side\n- [ ] SQL injection: all queries parameterized\n- [ ] XSS: user content sanitized, CSP configured\n- [ ] CSRF: protection enabled on state-changing routes\n- [ ] Authentication: proper token handling (httpOnly cookies)\n- [ ] Authorization: role/ownership checks in place on every route\n- [ ] Rate limiting: enabled on public and expensive endpoints\n- [ ] HTTPS enforced in production\n- [ ] Security headers configured (CSP, X-Frame-Options, etc.)\n- [ ] Error handling: no sensitive data in client-facing errors\n- [ ] Logging: no sensitive data logged\n- [ ] Dependencies: up to date, no known-high/critical vulnerabilities\n- [ ] Row-level security enabled where the database supports it\n- [ ] CORS properly scoped (no wildcard origin with credentials)\n- [ ] File uploads validated (size, type, extension)\n"
   },
   "skills": [
     {
@@ -21,15 +25,48 @@
       "description": "Use when code receives data from outside its own module — user input, API responses, file contents, env vars, message payloads — validate it against a schema at the boundary and fail fast, so untrusted shapes never propagate inward.",
       "body": "# Validate at boundaries\n\nEvery place external data enters your system is a boundary: an HTTP handler, a file read, an API\nresponse, an environment variable, a queue message. **Validate at the boundary, before the data\nreaches any logic that assumes it is well-formed.** Inside the boundary, the value is trusted because\nyou already checked it — not because you hope it is right.\n\n```ts\n// At the boundary: parse into a known shape, or reject.\nconst parsed = OrderSchema.parse(await req.json()); // throws on bad shape\ncreateOrder(parsed);                                 // inner code trusts `parsed`\n```\n\n## Rules\n\n- **One validator is the authority for each shape.** Route every entry point for that shape through\n  it — built-in, user-supplied, or machine-generated. Never hand-construct or trust an unvalidated\n  object further in.\n- **Fail fast, name the field.** Reject the whole input on the first violation with a message that\n  says which field was wrong and why. A vague \"invalid input\" costs the caller a debugging session.\n- **Parse, don't just check.** Return a typed value from validation so downstream code carries the\n  guarantee in its types, not just in a comment.\n- **Never trust \"internal\" data blindly.** An API response or a sibling service's payload is external\n  to your module even if it's inside your company — validate it the same way.\n\n## Why\n\nUnvalidated data that flows inward turns a boundary problem into a deep-stack mystery: the crash\nhappens three layers down, far from the malformed input that caused it. Validation at the edge keeps\nthe failure where the bad data actually entered, where the error message can still be specific.\n\n## Boundaries to cover\n\nHTTP request bodies and query params · file and config contents · third-party API responses ·\nenvironment variables (validate presence and format at startup) · deserialized messages/events ·\nanything read from a store you did not just write in the same transaction.\n",
       "category": "review"
+    },
+    {
+      "name": "security-review",
+      "description": "Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Full worked checklist with code examples for every OWASP Top 10 category, plus a cloud-infrastructure reference.",
+      "category": "review",
+      "body": "# Security review\n\nComprehensive security review discipline for code that adds authentication, handles user input, works with secrets, exposes an API endpoint, or touches payment/sensitive data. This is the full checklist version of the pack's own context — use it when you need the worked examples inline rather than the summary.\n\n## When to activate\n\n- Implementing authentication or authorization\n- Handling user input or file uploads\n- Creating new API endpoints\n- Working with secrets or credentials\n- Implementing payment features\n- Storing or transmitting sensitive data\n- Integrating third-party APIs\n\n## Secrets management\n\nFAIL:\n```typescript\nconst apiKey = \"sk-proj-xxxxx\" // hardcoded secret\nconst dbPassword = \"password123\" // in source code\n```\n\nPASS:\n```typescript\nconst apiKey = process.env.OPENAI_API_KEY\nif (!apiKey) throw new Error('OPENAI_API_KEY not configured')\n```\n\nVerify: no hardcoded API keys/tokens/passwords · all secrets in env vars · `.env.local` gitignored · no secrets in git history · production secrets in the hosting platform's secret store.\n\n## Input validation\n\n```typescript\nimport { z } from 'zod'\n\nconst CreateUserSchema = z.object({\n  email: z.string().email(),\n  name: z.string().min(1).max(100),\n  age: z.number().int().min(0).max(150)\n})\n\nexport async function createUser(input: unknown) {\n  try {\n    const validated = CreateUserSchema.parse(input)\n    return await db.users.create(validated)\n  } catch (error) {\n    if (error instanceof z.ZodError) return { success: false, errors: error.issues }\n    throw error\n  }\n}\n```\n\nFile upload validation checks size, MIME type, AND extension — never just one:\n\n```typescript\nfunction validateFileUpload(file: File) {\n  const maxSize = 5 * 1024 * 1024\n  if (file.size > maxSize) throw new Error('File too large (max 5MB)')\n\n  const allowedTypes = ['image/jpeg', 'image/png', 'image/gif']\n  if (!allowedTypes.includes(file.type)) throw new Error('Invalid file type')\n\n  const allowedExtensions = ['.jpg', '.jpeg', '.png', '.gif']\n  const extension = file.name.toLowerCase().match(/\\.[^.]+$/)?.[0]\n  if (!extension || !allowedExtensions.includes(extension)) throw new Error('Invalid file extension')\n\n  return true\n}\n```\n\nVerify: all user inputs validated with schemas · file uploads restricted (size, type, extension) · no direct use of user input in queries · whitelist validation (not blacklist) · error messages don't leak sensitive info.\n\n## SQL injection prevention\n\nFAIL:\n```typescript\nconst query = `SELECT * FROM users WHERE email = '${userEmail}'`\nawait db.query(query)\n```\n\nPASS:\n```typescript\nconst { data } = await supabase.from('users').select('*').eq('email', userEmail)\n// or\nawait db.query('SELECT * FROM users WHERE email = $1', [userEmail])\n```\n\nVerify: all database queries use parameterized queries · no string concatenation in SQL · ORM/query builder used correctly.\n\n## Authentication & authorization\n\n```typescript\n// FAIL: localStorage is vulnerable to XSS\nlocalStorage.setItem('token', token)\n\n// PASS: httpOnly cookie\nres.setHeader('Set-Cookie', `token=${token}; HttpOnly; Secure; SameSite=Strict; Max-Age=3600`)\n```\n\n```typescript\nexport async function deleteUser(userId: string, requesterId: string) {\n  const requester = await db.users.findUnique({ where: { id: requesterId } })\n  if (requester.role !== 'admin') {\n    return NextResponse.json({ error: 'Unauthorized' }, { status: 403 })\n  }\n  await db.users.delete({ where: { id: userId } })\n}\n```\n\nRow-level security (e.g. Supabase):\n\n```sql\nALTER TABLE users ENABLE ROW LEVEL SECURITY;\n\nCREATE POLICY \"Users view own data\" ON users FOR SELECT USING (auth.uid() = id);\nCREATE POLICY \"Users update own data\" ON users FOR UPDATE USING (auth.uid() = id);\n```\n\nVerify: tokens in httpOnly cookies (not localStorage) · authorization checks before sensitive operations · row-level security enabled where supported · role-based access control implemented · session management secure.\n\n## XSS prevention\n\n```typescript\nimport DOMPurify from 'isomorphic-dompurify'\n\nfunction renderUserContent(html: string) {\n  const clean = DOMPurify.sanitize(html, { ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'], ALLOWED_ATTR: [] })\n  return <div dangerouslySetInnerHTML={{ __html: clean }} />\n}\n```\n\nContent-Security-Policy — start strict and loosen only with a documented removal plan; don't default to `'unsafe-inline'` or `'unsafe-eval'`:\n\n```typescript\nconst securityHeaders = [{\n  key: 'Content-Security-Policy',\n  value: `\n    default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none';\n    script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self';\n    connect-src 'self' https://api.example.com;\n  `.replace(/\\s{2,}/g, ' ').trim()\n}]\n```\n\nVerify: user-provided HTML sanitized · CSP headers configured · no unvalidated dynamic content rendering · framework's built-in XSS protection used, not bypassed.\n\n## CSRF protection\n\n```typescript\nexport async function POST(request: Request) {\n  const token = request.headers.get('X-CSRF-Token')\n  if (!csrf.verify(token)) return NextResponse.json({ error: 'Invalid CSRF token' }, { status: 403 })\n}\n```\n\n```typescript\nres.setHeader('Set-Cookie', `session=${sessionId}; HttpOnly; Secure; SameSite=Strict`)\n```\n\nVerify: CSRF tokens on state-changing operations · `SameSite=Strict` on all cookies · double-submit cookie pattern where applicable.\n\n## Rate limiting\n\n```typescript\nimport rateLimit from 'express-rate-limit'\n\nconst limiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 100, message: 'Too many requests' })\napp.use('/api/', limiter)\n\nconst searchLimiter = rateLimit({ windowMs: 60 * 1000, max: 10, message: 'Too many search requests' })\napp.use('/api/search', searchLimiter)\n```\n\nVerify: rate limiting on all API endpoints · stricter limits on expensive operations · IP-based and, where authenticated, user-based limits.\n\n## Sensitive data exposure\n\n```typescript\n// FAIL\nconsole.log('User login:', { email, password })\nconsole.log('Payment:', { cardNumber, cvv })\n\n// PASS\nconsole.log('User login:', { email, userId })\nconsole.log('Payment:', { last4: card.last4, userId })\n```\n\n```typescript\n// FAIL\ncatch (error) {\n  return NextResponse.json({ error: error.message, stack: error.stack }, { status: 500 })\n}\n\n// PASS\ncatch (error) {\n  console.error('Internal error:', error)\n  return NextResponse.json({ error: 'An error occurred. Please try again.' }, { status: 500 })\n}\n```\n\nVerify: no passwords/tokens/secrets in logs · error messages generic for users · detailed errors server-side only · no stack traces exposed to users.\n\n## Signed-transaction verification (any system that signs/authorizes value transfer)\n\nWherever a system accepts a signed message or transaction authorizing a transfer of value (payments, on-chain transactions, signed API mutations), verify the signature AND re-check business constraints server-side — never trust a client-reported amount or recipient:\n\n```typescript\nasync function verifyTransaction(transaction: Transaction) {\n  if (transaction.to !== expectedRecipient) throw new Error('Invalid recipient')\n  if (transaction.amount > maxAmount) throw new Error('Amount exceeds limit')\n  const balance = await getBalance(transaction.from)\n  if (balance < transaction.amount) throw new Error('Insufficient balance')\n  return true\n}\n```\n\nVerify: signatures verified · transaction/mutation details re-validated server-side · balance/limit checks before committing · no blind signing of client-supplied payloads.\n\n## Dependency security\n\n```bash\nnpm audit\nnpm audit fix\nnpm update\nnpm outdated\n```\n\n```bash\ngit add package-lock.json   # always commit lock files\nnpm ci                      # in CI, for reproducible builds\n```\n\nVerify: dependencies up to date · no known vulnerabilities (`npm audit` clean) · lock files committed · automated dependency update tooling enabled · regular security updates.\n\n## Security testing\n\n```typescript\ntest('requires authentication', async () => {\n  const response = await fetch('/api/protected')\n  expect(response.status).toBe(401)\n})\n\ntest('requires admin role', async () => {\n  const response = await fetch('/api/admin', { headers: { Authorization: `Bearer ${userToken}` } })\n  expect(response.status).toBe(403)\n})\n\ntest('rejects invalid input', async () => {\n  const response = await fetch('/api/users', { method: 'POST', body: JSON.stringify({ email: 'not-an-email' }) })\n  expect(response.status).toBe(400)\n})\n\ntest('enforces rate limits', async () => {\n  const requests = Array(101).fill(null).map(() => fetch('/api/endpoint'))\n  const responses = await Promise.all(requests)\n  expect(responses.filter(r => r.status === 429).length).toBeGreaterThan(0)\n})\n```\n\n## Pre-deployment security checklist\n\nBefore ANY production deployment:\n\n- [ ] Secrets: no hardcoded secrets, all in env vars\n- [ ] Input validation: all user inputs validated\n- [ ] SQL injection: all queries parameterized\n- [ ] XSS: user content sanitized\n- [ ] CSRF: protection enabled\n- [ ] Authentication: proper token handling\n- [ ] Authorization: role checks in place\n- [ ] Rate limiting: enabled on all endpoints\n- [ ] HTTPS: enforced in production\n- [ ] Security headers: CSP, X-Frame-Options configured\n- [ ] Error handling: no sensitive data in errors\n- [ ] Logging: no sensitive data logged\n- [ ] Dependencies: up to date, no vulnerabilities\n- [ ] Row-level security: enabled where supported\n- [ ] CORS: properly configured\n- [ ] File uploads: validated (size, type)\n- [ ] Signed transactions: signatures and business constraints re-verified server-side (if applicable)\n\n## Common false positives\n\n- Environment variables in `.env.example` (not actual secrets)\n- Test credentials in test files, clearly marked as such\n- Public API keys that are actually meant to be public\n- SHA-256/MD5 used for checksums, not password storage\n\nAlways verify context before flagging.\n\n## Resources\n\n- [OWASP Top 10](https://owasp.org/www-project-top-ten/)\n- [Web Security Academy](https://portswigger.net/web-security)\n",
+      "references": [
+        {
+          "name": "cloud-infrastructure-security",
+          "body": "# Cloud & infrastructure security\n\nUse when deploying to cloud platforms, configuring infrastructure, managing IAM policies, setting up logging/monitoring, or implementing CI/CD pipelines.\n\n## When to activate\n\n- Deploying applications to cloud platforms\n- Configuring IAM roles and permissions\n- Setting up CI/CD pipelines\n- Implementing infrastructure as code (Terraform, CloudFormation)\n- Configuring logging and monitoring\n- Managing secrets in cloud environments\n- Setting up CDN and edge security\n- Implementing disaster recovery and backup strategies\n\n## IAM & access control\n\nPrinciple of least privilege:\n\n```yaml\n# PASS\niam_role:\n  permissions: [s3:GetObject, s3:ListBucket]\n  resources: [arn:aws:s3:::my-bucket/*]\n\n# FAIL\niam_role:\n  permissions: [s3:*]\n  resources: [\"*\"]\n```\n\nVerify: no root account usage in production · MFA enabled for all privileged accounts · service accounts use roles, not long-lived credentials · IAM policies follow least privilege · regular access reviews · unused credentials rotated or removed.\n\n## Secrets management\n\n```typescript\n// PASS — cloud secrets manager\nimport { SecretsManager } from '@aws-sdk/client-secrets-manager'\nconst client = new SecretsManager({ region: 'us-east-1' })\nconst secret = await client.getSecretValue({ SecretId: 'prod/api-key' })\n\n// FAIL — env var only, not rotated, not audited, for a long-lived production credential\nconst apiKey = process.env.API_KEY\n```\n\nVerify: secrets in a cloud secrets manager · automatic rotation for database credentials · API keys rotated at least quarterly · no secrets in code, logs, or error messages · audit logging on secret access.\n\n## Network security\n\n```terraform\n# PASS — restricted security group\nresource \"aws_security_group\" \"app\" {\n  ingress { from_port = 443; to_port = 443; protocol = \"tcp\"; cidr_blocks = [\"10.0.0.0/16\"] }\n  egress  { from_port = 443; to_port = 443; protocol = \"tcp\"; cidr_blocks = [\"0.0.0.0/0\"] }\n}\n\n# FAIL — open to the internet\nresource \"aws_security_group\" \"bad\" {\n  ingress { from_port = 0; to_port = 65535; protocol = \"tcp\"; cidr_blocks = [\"0.0.0.0/0\"] }\n}\n```\n\nVerify: database not publicly accessible · SSH/RDP restricted to VPN/bastion · security groups follow least privilege · network ACLs configured · VPC flow logs enabled.\n\n## Logging & monitoring\n\nLog security events with enough structure to alert on, never with sensitive payloads:\n\n```typescript\nconst logSecurityEvent = async (event: SecurityEvent) => {\n  await cloudwatch.putLogEvents({\n    logGroupName: '/aws/security/events',\n    logStreamName: 'authentication',\n    logEvents: [{ timestamp: Date.now(), message: JSON.stringify({\n      type: event.type, userId: event.userId, ip: event.ip, result: event.result\n      // never log sensitive data\n    }) }]\n  })\n}\n```\n\nVerify: logging enabled for all services · failed auth attempts logged · admin actions audited · retention configured (90+ days for compliance) · alerts on suspicious activity · logs centralized and tamper-proof.\n\n## CI/CD pipeline security\n\n```yaml\nname: Deploy\non: { push: { branches: [main] } }\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    permissions: { contents: read }   # minimal permissions\n    steps:\n      - uses: actions/checkout@v4\n      - name: Secret scanning\n        uses: trufflesecurity/trufflehog@main\n      - name: Audit dependencies\n        run: npm audit --audit-level=high\n      - name: Configure AWS credentials   # OIDC, not long-lived tokens\n        uses: aws-actions/configure-aws-credentials@v4\n        with: { role-to-assume: \"arn:aws:iam::123456789:role/GitHubActionsRole\", aws-region: us-east-1 }\n```\n\nVerify: OIDC instead of long-lived credentials · secrets scanning in the pipeline · dependency vulnerability scanning · container image scanning where applicable · branch protection enforced · review required before merge · signed commits enforced where the project requires it.\n\n## CDN & edge security\n\n```typescript\nexport default {\n  async fetch(request: Request): Promise<Response> {\n    const response = await fetch(request)\n    const headers = new Headers(response.headers)\n    headers.set('X-Frame-Options', 'DENY')\n    headers.set('X-Content-Type-Options', 'nosniff')\n    headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')\n    headers.set('Permissions-Policy', 'geolocation=(), microphone=()')\n    return new Response(response.body, { status: response.status, headers })\n  }\n}\n```\n\nVerify: WAF enabled with a managed ruleset · rate limiting configured at the edge · bot protection active · DDoS protection enabled · security headers configured · TLS strict mode enabled.\n\n## Backup & disaster recovery\n\n```terraform\nresource \"aws_db_instance\" \"main\" {\n  backup_retention_period = 30\n  backup_window           = \"03:00-04:00\"\n  deletion_protection     = true\n}\n```\n\nVerify: automated daily backups · retention meets compliance requirements · point-in-time recovery enabled · backup restore tested quarterly · disaster recovery plan documented · RPO/RTO defined and tested.\n\n## Common cloud misconfigurations\n\n```bash\n# FAIL — public bucket\naws s3api put-bucket-acl --bucket my-bucket --acl public-read\n# PASS — private bucket, explicit policy\naws s3api put-bucket-acl --bucket my-bucket --acl private\n```\n\n```terraform\n# FAIL\nresource \"aws_db_instance\" \"bad\" { publicly_accessible = true }\n# PASS\nresource \"aws_db_instance\" \"good\" { publicly_accessible = false }\n```\n\n## Pre-deployment cloud checklist\n\n- [ ] IAM: root unused, MFA enabled, least-privilege policies\n- [ ] Secrets: cloud secrets manager with rotation\n- [ ] Network: security groups restricted, no public databases\n- [ ] Logging: enabled with retention\n- [ ] Monitoring: alerts configured for anomalies\n- [ ] CI/CD: OIDC auth, secrets scanning, dependency audits\n- [ ] CDN/WAF: enabled with a managed ruleset\n- [ ] Encryption: data encrypted at rest and in transit\n- [ ] Backups: automated with tested recovery\n- [ ] Compliance: applicable requirements (GDPR/HIPAA/etc.) met\n- [ ] Documentation: infrastructure documented, runbooks created\n- [ ] Incident response plan in place\n\n## Resources\n\n- [AWS Security Best Practices](https://aws.amazon.com/security/best-practices/)\n- [CIS AWS Foundations Benchmark](https://www.cisecurity.org/benchmark/amazon_web_services)\n- [OWASP Cloud Security](https://owasp.org/www-project-cloud-security/)\n"
+        }
+      ],
+      "attribution": {
+        "source": "affaan-m/ECC (Everything Claude Code)",
+        "url": "https://github.com/affaan-m/ECC",
+        "license": "MIT"
+      }
+    },
+    {
+      "name": "security-scan-config",
+      "description": "Scan this project's AI-harness configuration (settings, CLAUDE.md/AGENTS.md, MCP servers, hooks, agent definitions) for secrets, dangerous permission bypasses, and prompt-injection risk — before committing configuration changes.",
+      "category": "review",
+      "body": "# Security scan (harness configuration)\n\nScan this project's AI-harness configuration (`.claude/` or equivalent) for security misconfigurations and prompt-injection risk — a separate concern from application code, but part of the same trust boundary in an AI-assisted repo.\n\n## When to activate\n\n- Setting up a new AI-harness project configuration\n- After modifying `settings.json`, `CLAUDE.md`/`AGENTS.md`, or MCP server configs\n- Before committing configuration changes\n- When onboarding to a repo with an existing harness configuration\n- Periodic security hygiene checks\n\n## What to review\n\n| File | Checks |\n| --- | --- |\n| `CLAUDE.md` / `AGENTS.md` | Hardcoded secrets, auto-run instructions embedded in project docs, prompt-injection patterns |\n| `settings.json` | Overly permissive allow lists, missing deny lists, dangerous bypass flags (e.g. skip-permissions) |\n| MCP server config | Risky/unaudited servers, hardcoded secrets in server env, unpinned `npx`-style install-on-run entries |\n| hooks | Command injection via unescaped interpolation into a shell command, silent error suppression (`2>/dev/null`, `\\|\\| true`), unexplained outbound network calls |\n| agent definitions | Unrestricted tool access (e.g. unconditional Bash) where the task doesn't need it, missing model spec, prompt-injection surface from untrusted inputs |\n\n## Manual scan (portable, no extra tooling)\n\n```bash\n# hardcoded-looking secrets in harness config\ngrep -rEn '(api[_-]?key|secret|token|password)\\s*[:=]\\s*[\"\\x27][A-Za-z0-9/+=_-]{12,}' .claude/ CLAUDE.md AGENTS.md 2>/dev/null\n\n# unrestricted shell / dangerous bypass flags\ngrep -rn 'Bash(\\*)\\|dangerously-skip-permissions\\|--no-verify' .claude/settings*.json 2>/dev/null\n\n# hook commands that interpolate a file path or tool output directly into a shell string\ngrep -rn '${.*}|$(.*)' .claude/settings*.json 2>/dev/null | grep -i hook\n\n# silent error suppression in hooks (hides a failing check rather than fixing it)\ngrep -rn '2>/dev/null\\|\\|\\| true' .claude/settings*.json 2>/dev/null\n```\n\n## Severity levels\n\n- **CRITICAL** — hardcoded API keys/tokens in config; `Bash(*)` (or equivalent unrestricted shell) in the allow list; command injection in a hook via unescaped interpolation; a shell-executing MCP server with no scoping.\n- **HIGH** — auto-run instructions embedded in project docs (a prompt-injection vector any collaborator's harness will read); missing deny lists on sensitive paths (`~/.ssh`, `~/.aws`, `.env*`); an agent with Bash access it doesn't need for its stated task.\n- **MEDIUM** — silent error suppression in hooks; missing a pre-tool-use security hook on Bash; unpinned install-on-run entries in MCP server config.\n- **INFO** — missing descriptions on MCP servers or agents; explicit prohibitive instructions correctly present (flag as good practice, not a finding).\n\n## Resources\n\n- [OWASP MCP Top 10](https://owasp.org/) — tool poisoning, prompt injection via contextual payloads, command injection, shadow MCP servers, secret exposure.\n",
+      "attribution": {
+        "source": "affaan-m/ECC (Everything Claude Code)",
+        "url": "https://github.com/affaan-m/ECC",
+        "license": "MIT"
+      }
     }
   ],
   "agents": [
     {
       "name": "security-reviewer",
-      "description": "Flags real vulnerabilities (injection, authz gaps, secrets, unsafe deserialization, SSRF, XSS) with severity and file:line. Use after writing code that touches user input, auth, or sensitive data, and before any release.",
-      "tools": ["Read", "Grep", "Glob", "Bash"],
+      "description": "Flags real vulnerabilities (injection, authz gaps, secrets, unsafe deserialization, SSRF, XSS, and the rest of the OWASP Top 10) with severity, file:line, and a concrete fix. Use after writing code that touches user input, auth, or sensitive data, and before any release.",
+      "tools": [
+        "Read",
+        "Grep",
+        "Glob",
+        "Bash"
+      ],
       "model": "sonnet",
-      "prompt": "You are a security reviewer. Read the changed code and check it against the security-review checklist in context: injection, authorization, hardcoded secrets, unsafe deserialization, SSRF, XSS, and sensitive-data logging. For each finding, cite the exact file:line, name the concrete input and outcome that makes it exploitable, and give severity (CRITICAL/HIGH/MEDIUM). Skip findings you cannot point to in the code — do not manufacture issues to look thorough. If nothing is exploitable, say so and approve."
+      "prompt": "You are an expert security reviewer focused on identifying and remediating real vulnerabilities before they reach production. Read the changed code and check it against the security-review checklist in this pack's context: injection, broken authentication, sensitive data exposure, broken access control, security misconfiguration, XSS, insecure deserialization, known-vulnerable dependencies, insufficient logging, SSRF, and hardcoded secrets.\n\n## Review workflow\n\n1. **Initial scan** — search the diff (and, if relevant, git history) for hardcoded secrets; identify high-risk areas touched: auth, API endpoints, DB queries, file uploads, payments, webhooks, MCP/agent configuration.\n2. **OWASP Top 10 pass** — work through each of the 10 categories in this pack's context against the actual code, not in the abstract.\n3. **Pattern match** — flag any of this pack's known-bad patterns on sight (hardcoded secret, shell command built from user input, string-concatenated SQL, unsanitized `innerHTML`, unallow-listed `fetch(userUrl)`, plaintext password comparison, missing auth check, unlocked balance/quantity check, missing rate limiting, secrets in logs).\n\n## Reporting\n\nFor each finding, cite the exact file:line, name the concrete input and outcome that makes it exploitable, and give a severity:\n\n- **CRITICAL** — hardcoded secrets, injection, auth bypass. Blocks merge.\n- **HIGH** — XSS/SSRF without an allow-list, a BOLA/IDOR gap, unrestricted shell access.\n- **MEDIUM** — missing rate limiting, verbose error messages, silent error suppression.\n- **INFO** — hygiene items (missing descriptions, outdated-but-non-vulnerable dependency).\n\nFor every finding, give a concrete fix — a corrected code snippet, not just a description of the problem. Skip findings you cannot point to in the code; do not manufacture issues to look thorough. Common false positives to verify context on before flagging: `.env.example` placeholders, clearly-marked test credentials, intentionally-public API keys, and SHA-256/MD5 used for checksums rather than password storage.\n\n## When to run\n\nAlways after: new API endpoints, auth code changes, user input handling, DB query changes, file uploads, payment code, external API integrations, dependency updates, or changes to this project's own AI-harness configuration (hooks, MCP servers, agent/skill definitions). Immediately for: production incidents, dependency CVEs, user security reports, or before any major release.\n\n## Reference\n\nFor the full worked checklist with code examples, see the `security-review` skill in this pack (and its `cloud-infrastructure-security` reference for deploy-touching changes). For the 4-layer pre-deploy pass, see the `security-audit` skill.\n\n**Remember**: be thorough and specific, not performative. One real, well-cited finding is worth more than ten vague ones."
     }
   ],
   "commands": [
@@ -47,6 +84,13 @@
     }
   ],
   "hooks": [
+    {
+      "event": "PreToolUse",
+      "matcher": "Bash",
+      "description": "Before any shell command, remind never to echo, print, or log a live secret value.",
+      "action": "print-reminder",
+      "message": "Security check: never paste or echo a live secret (API key, token, cookie, password, .pem contents) into this command's output or a log — reference an environment variable or secret manager instead."
+    },
     {
       "event": "PostToolUse",
       "matcher": "Edit|Write",

package/packs/security-review/rendered/.claude/agents/security-reviewer.md

@@ -1,8 +1,35 @@
 ---
 name: security-reviewer
-description: Flags real vulnerabilities (injection, authz gaps, secrets, unsafe deserialization, SSRF, XSS) with severity and file:line. Use after writing code that touches user input, auth, or sensitive data, and before any release.
+description: Flags real vulnerabilities (injection, authz gaps, secrets, unsafe deserialization, SSRF, XSS, and the rest of the OWASP Top 10) with severity, file:line, and a concrete fix. Use after writing code that touches user input, auth, or sensitive data, and before any release.
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
-You are a security reviewer. Read the changed code and check it against the security-review checklist in context: injection, authorization, hardcoded secrets, unsafe deserialization, SSRF, XSS, and sensitive-data logging. For each finding, cite the exact file:line, name the concrete input and outcome that makes it exploitable, and give severity (CRITICAL/HIGH/MEDIUM). Skip findings you cannot point to in the code — do not manufacture issues to look thorough. If nothing is exploitable, say so and approve.
+You are an expert security reviewer focused on identifying and remediating real vulnerabilities before they reach production. Read the changed code and check it against the security-review checklist in this pack's context: injection, broken authentication, sensitive data exposure, broken access control, security misconfiguration, XSS, insecure deserialization, known-vulnerable dependencies, insufficient logging, SSRF, and hardcoded secrets.
+
+## Review workflow
+
+1. **Initial scan** — search the diff (and, if relevant, git history) for hardcoded secrets; identify high-risk areas touched: auth, API endpoints, DB queries, file uploads, payments, webhooks, MCP/agent configuration.
+2. **OWASP Top 10 pass** — work through each of the 10 categories in this pack's context against the actual code, not in the abstract.
+3. **Pattern match** — flag any of this pack's known-bad patterns on sight (hardcoded secret, shell command built from user input, string-concatenated SQL, unsanitized `innerHTML`, unallow-listed `fetch(userUrl)`, plaintext password comparison, missing auth check, unlocked balance/quantity check, missing rate limiting, secrets in logs).
+
+## Reporting
+
+For each finding, cite the exact file:line, name the concrete input and outcome that makes it exploitable, and give a severity:
+
+- **CRITICAL** — hardcoded secrets, injection, auth bypass. Blocks merge.
+- **HIGH** — XSS/SSRF without an allow-list, a BOLA/IDOR gap, unrestricted shell access.
+- **MEDIUM** — missing rate limiting, verbose error messages, silent error suppression.
+- **INFO** — hygiene items (missing descriptions, outdated-but-non-vulnerable dependency).
+
+For every finding, give a concrete fix — a corrected code snippet, not just a description of the problem. Skip findings you cannot point to in the code; do not manufacture issues to look thorough. Common false positives to verify context on before flagging: `.env.example` placeholders, clearly-marked test credentials, intentionally-public API keys, and SHA-256/MD5 used for checksums rather than password storage.
+
+## When to run
+
+Always after: new API endpoints, auth code changes, user input handling, DB query changes, file uploads, payment code, external API integrations, dependency updates, or changes to this project's own AI-harness configuration (hooks, MCP servers, agent/skill definitions). Immediately for: production incidents, dependency CVEs, user security reports, or before any major release.
+
+## Reference
+
+For the full worked checklist with code examples, see the `security-review` skill in this pack (and its `cloud-infrastructure-security` reference for deploy-touching changes). For the 4-layer pre-deploy pass, see the `security-audit` skill.
+
+**Remember**: be thorough and specific, not performative. One real, well-cited finding is worth more than ten vague ones.

package/packs/security-review/rendered/.claude/settings.json

@@ -1,5 +1,16 @@
 {
   "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Security check: never paste or echo a live secret (API key, token, cookie, password, .pem contents) into this command's output or a log — reference an environment variable or secret manager instead.\""
+          }
+        ]
+      }
+    ],
     "PostToolUse": [
       {
         "matcher": "Edit|Write",

package/packs/security-review/rendered/.claude/skills/security-review/SKILL.md

@@ -0,0 +1,302 @@
+---
+name: security-review
+description: Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Full worked checklist with code examples for every OWASP Top 10 category, plus a cloud-infrastructure reference.
+license: MIT
+---
+
+<!-- adapted from affaan-m/ECC (Everything Claude Code) (MIT) — https://github.com/affaan-m/ECC -->
+
+# Security review
+
+Comprehensive security review discipline for code that adds authentication, handles user input, works with secrets, exposes an API endpoint, or touches payment/sensitive data. This is the full checklist version of the pack's own context — use it when you need the worked examples inline rather than the summary.
+
+## When to activate
+
+- Implementing authentication or authorization
+- Handling user input or file uploads
+- Creating new API endpoints
+- Working with secrets or credentials
+- Implementing payment features
+- Storing or transmitting sensitive data
+- Integrating third-party APIs
+
+## Secrets management
+
+FAIL:
+```typescript
+const apiKey = "sk-proj-xxxxx" // hardcoded secret
+const dbPassword = "password123" // in source code
+```
+
+PASS:
+```typescript
+const apiKey = process.env.OPENAI_API_KEY
+if (!apiKey) throw new Error('OPENAI_API_KEY not configured')
+```
+
+Verify: no hardcoded API keys/tokens/passwords · all secrets in env vars · `.env.local` gitignored · no secrets in git history · production secrets in the hosting platform's secret store.
+
+## Input validation
+
+```typescript
+import { z } from 'zod'
+
+const CreateUserSchema = z.object({
+  email: z.string().email(),
+  name: z.string().min(1).max(100),
+  age: z.number().int().min(0).max(150)
+})
+
+export async function createUser(input: unknown) {
+  try {
+    const validated = CreateUserSchema.parse(input)
+    return await db.users.create(validated)
+  } catch (error) {
+    if (error instanceof z.ZodError) return { success: false, errors: error.issues }
+    throw error
+  }
+}
+```
+
+File upload validation checks size, MIME type, AND extension — never just one:
+
+```typescript
+function validateFileUpload(file: File) {
+  const maxSize = 5 * 1024 * 1024
+  if (file.size > maxSize) throw new Error('File too large (max 5MB)')
+
+  const allowedTypes = ['image/jpeg', 'image/png', 'image/gif']
+  if (!allowedTypes.includes(file.type)) throw new Error('Invalid file type')
+
+  const allowedExtensions = ['.jpg', '.jpeg', '.png', '.gif']
+  const extension = file.name.toLowerCase().match(/\.[^.]+$/)?.[0]
+  if (!extension || !allowedExtensions.includes(extension)) throw new Error('Invalid file extension')
+
+  return true
+}
+```
+
+Verify: all user inputs validated with schemas · file uploads restricted (size, type, extension) · no direct use of user input in queries · whitelist validation (not blacklist) · error messages don't leak sensitive info.
+
+## SQL injection prevention
+
+FAIL:
+```typescript
+const query = `SELECT * FROM users WHERE email = '${userEmail}'`
+await db.query(query)
+```
+
+PASS:
+```typescript
+const { data } = await supabase.from('users').select('*').eq('email', userEmail)
+// or
+await db.query('SELECT * FROM users WHERE email = $1', [userEmail])
+```
+
+Verify: all database queries use parameterized queries · no string concatenation in SQL · ORM/query builder used correctly.
+
+## Authentication & authorization
+
+```typescript
+// FAIL: localStorage is vulnerable to XSS
+localStorage.setItem('token', token)
+
+// PASS: httpOnly cookie
+res.setHeader('Set-Cookie', `token=${token}; HttpOnly; Secure; SameSite=Strict; Max-Age=3600`)
+```
+
+```typescript
+export async function deleteUser(userId: string, requesterId: string) {
+  const requester = await db.users.findUnique({ where: { id: requesterId } })
+  if (requester.role !== 'admin') {
+    return NextResponse.json({ error: 'Unauthorized' }, { status: 403 })
+  }
+  await db.users.delete({ where: { id: userId } })
+}
+```
+
+Row-level security (e.g. Supabase):
+
+```sql
+ALTER TABLE users ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY "Users view own data" ON users FOR SELECT USING (auth.uid() = id);
+CREATE POLICY "Users update own data" ON users FOR UPDATE USING (auth.uid() = id);
+```
+
+Verify: tokens in httpOnly cookies (not localStorage) · authorization checks before sensitive operations · row-level security enabled where supported · role-based access control implemented · session management secure.
+
+## XSS prevention
+
+```typescript
+import DOMPurify from 'isomorphic-dompurify'
+
+function renderUserContent(html: string) {
+  const clean = DOMPurify.sanitize(html, { ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'], ALLOWED_ATTR: [] })
+  return <div dangerouslySetInnerHTML={{ __html: clean }} />
+}
+```
+
+Content-Security-Policy — start strict and loosen only with a documented removal plan; don't default to `'unsafe-inline'` or `'unsafe-eval'`:
+
+```typescript
+const securityHeaders = [{
+  key: 'Content-Security-Policy',
+  value: `
+    default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none';
+    script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self';
+    connect-src 'self' https://api.example.com;
+  `.replace(/\s{2,}/g, ' ').trim()
+}]
+```
+
+Verify: user-provided HTML sanitized · CSP headers configured · no unvalidated dynamic content rendering · framework's built-in XSS protection used, not bypassed.
+
+## CSRF protection
+
+```typescript
+export async function POST(request: Request) {
+  const token = request.headers.get('X-CSRF-Token')
+  if (!csrf.verify(token)) return NextResponse.json({ error: 'Invalid CSRF token' }, { status: 403 })
+}
+```
+
+```typescript
+res.setHeader('Set-Cookie', `session=${sessionId}; HttpOnly; Secure; SameSite=Strict`)
+```
+
+Verify: CSRF tokens on state-changing operations · `SameSite=Strict` on all cookies · double-submit cookie pattern where applicable.
+
+## Rate limiting
+
+```typescript
+import rateLimit from 'express-rate-limit'
+
+const limiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 100, message: 'Too many requests' })
+app.use('/api/', limiter)
+
+const searchLimiter = rateLimit({ windowMs: 60 * 1000, max: 10, message: 'Too many search requests' })
+app.use('/api/search', searchLimiter)
+```
+
+Verify: rate limiting on all API endpoints · stricter limits on expensive operations · IP-based and, where authenticated, user-based limits.
+
+## Sensitive data exposure
+
+```typescript
+// FAIL
+console.log('User login:', { email, password })
+console.log('Payment:', { cardNumber, cvv })
+
+// PASS
+console.log('User login:', { email, userId })
+console.log('Payment:', { last4: card.last4, userId })
+```
+
+```typescript
+// FAIL
+catch (error) {
+  return NextResponse.json({ error: error.message, stack: error.stack }, { status: 500 })
+}
+
+// PASS
+catch (error) {
+  console.error('Internal error:', error)
+  return NextResponse.json({ error: 'An error occurred. Please try again.' }, { status: 500 })
+}
+```
+
+Verify: no passwords/tokens/secrets in logs · error messages generic for users · detailed errors server-side only · no stack traces exposed to users.
+
+## Signed-transaction verification (any system that signs/authorizes value transfer)
+
+Wherever a system accepts a signed message or transaction authorizing a transfer of value (payments, on-chain transactions, signed API mutations), verify the signature AND re-check business constraints server-side — never trust a client-reported amount or recipient:
+
+```typescript
+async function verifyTransaction(transaction: Transaction) {
+  if (transaction.to !== expectedRecipient) throw new Error('Invalid recipient')
+  if (transaction.amount > maxAmount) throw new Error('Amount exceeds limit')
+  const balance = await getBalance(transaction.from)
+  if (balance < transaction.amount) throw new Error('Insufficient balance')
+  return true
+}
+```
+
+Verify: signatures verified · transaction/mutation details re-validated server-side · balance/limit checks before committing · no blind signing of client-supplied payloads.
+
+## Dependency security
+
+```bash
+npm audit
+npm audit fix
+npm update
+npm outdated
+```
+
+```bash
+git add package-lock.json   # always commit lock files
+npm ci                      # in CI, for reproducible builds
+```
+
+Verify: dependencies up to date · no known vulnerabilities (`npm audit` clean) · lock files committed · automated dependency update tooling enabled · regular security updates.
+
+## Security testing
+
+```typescript
+test('requires authentication', async () => {
+  const response = await fetch('/api/protected')
+  expect(response.status).toBe(401)
+})
+
+test('requires admin role', async () => {
+  const response = await fetch('/api/admin', { headers: { Authorization: `Bearer ${userToken}` } })
+  expect(response.status).toBe(403)
+})
+
+test('rejects invalid input', async () => {
+  const response = await fetch('/api/users', { method: 'POST', body: JSON.stringify({ email: 'not-an-email' }) })
+  expect(response.status).toBe(400)
+})
+
+test('enforces rate limits', async () => {
+  const requests = Array(101).fill(null).map(() => fetch('/api/endpoint'))
+  const responses = await Promise.all(requests)
+  expect(responses.filter(r => r.status === 429).length).toBeGreaterThan(0)
+})
+```
+
+## Pre-deployment security checklist
+
+Before ANY production deployment:
+
+- [ ] Secrets: no hardcoded secrets, all in env vars
+- [ ] Input validation: all user inputs validated
+- [ ] SQL injection: all queries parameterized
+- [ ] XSS: user content sanitized
+- [ ] CSRF: protection enabled
+- [ ] Authentication: proper token handling
+- [ ] Authorization: role checks in place
+- [ ] Rate limiting: enabled on all endpoints
+- [ ] HTTPS: enforced in production
+- [ ] Security headers: CSP, X-Frame-Options configured
+- [ ] Error handling: no sensitive data in errors
+- [ ] Logging: no sensitive data logged
+- [ ] Dependencies: up to date, no vulnerabilities
+- [ ] Row-level security: enabled where supported
+- [ ] CORS: properly configured
+- [ ] File uploads: validated (size, type)
+- [ ] Signed transactions: signatures and business constraints re-verified server-side (if applicable)
+
+## Common false positives
+
+- Environment variables in `.env.example` (not actual secrets)
+- Test credentials in test files, clearly marked as such
+- Public API keys that are actually meant to be public
+- SHA-256/MD5 used for checksums, not password storage
+
+Always verify context before flagging.
+
+## Resources
+
+- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
+- [Web Security Academy](https://portswigger.net/web-security)