/sota-code-security

name: sota-code-security
description: >-
  Secure coding and security auditing rules. Use whenever
  BUILDING or modifying code that crosses a trust boundary — endpoints,
  handlers, auth/login/signup, sessions, JWT/OAuth, file uploads, payments,
  multi-tenant features, crypto/secrets handling, parsers, CLI/exec wrappers,
  LLM agents or tool-calling — AND whenever AUDITING code for security
  (security review, vulnerability hunt, hardening, OWASP, CWE, secrets leak,
  "is this code safe") — AND whenever a control is already PRESENT and the
  question is whether it enforces anything (a gate that never fails, an empty
  comparand), even when that control lives in a shell script, a CI step or a
  config file. Trigger keywords: secure, security, vulnerability, audit, authn,
  authz, authentication, authorization, crypto, TLS, sanitize, validate,
  injection, SQLi, XSS, CSRF, SSRF, IDOR, JWT, OAuth, upload, rate limit,
  prompt injection, feed, parser, decompression bomb, webhook, deserialization,
  silent failure, fail-open, no-op control, business logic.

SOTA Code Security

Purpose

One skill, two modes. The `rules/` files define the 2026 secure-coding baseline (OWASP Top 10 2025/API 2023/LLM + Agentic Top 10, CWE-mapped). In **BUILD** mode you write code that conforms to the rules by default. In **AUDIT** mode you hunt for violations of the same rules and report them as severity-rated findings. The rules are the single source of truth for both — anything a rules file forbids is a finding; anything it mandates is the implementation default.

Threat-model framing for both modes: every input is hostile until validated at a trust boundary; every output channel (response, error, log, model context) is adversary-readable; every privileged operation needs an explicit, code-enforced (never prompt-, comment-, or convention-enforced) authorization decision.

BUILD mode — secure-by-default while writing code

1. **Identify trust boundaries first.** Before writing a handler/parser/job, name what crosses in (user input, third-party content, model output, file bytes) and what authority the code wields. Pick the relevant rules files from the index below and follow them as you write — not as a review pass. 2. **Defaults, not options.** Use the rules' default choices without being asked: parameterized queries, argv-exec, argon2id, AEAD via libsodium-class libraries, `__Host-` cookies, allowlist DTOs (`extra=forbid`), deny-by-default route policy, per-principal rate limits, timeouts on every outbound call. Abuse that rate limits do not stop (fake signups, scraping, credential stuffing at low rate): [rules/19](rules/19-anti-automation-and-abuse.md). 3. **Structural over disciplinary.** Prefer designs where the insecure variant cannot be written: ownership predicates inside queries, RLS for tenancy, typed Secret wrappers with masked repr, central crypto/authz modules, logger redaction filters. If safety depends on every future dev remembering a rule, redesign. 4. **Never hand-roll** crypto, session machinery, password hashing, JWT/OAuth protocol steps, HTML sanitizers, or auth token schemes. Compose vetted libraries per [rules/02](rules/02-authentication.md), [rules/17](rules/17-sessions-and-tokens.md) and [rules/04](rules/04-cryptography.md). 5. **When requirements force a deviation** (e.g. shell-out unavoidable, CORS must reflect origins), implement the rules file's documented mitigation stack and leave a `SECURITY:` comment stating the residual risk. 6. **Every control must be falsifiable.** For each control you add, ask: *if this were silently a no-op, would anything observable differ?* If nothing would — no log, no metric, no failing test — the control is not finished. Assert on real loaded artifacts (not `exists()`), fail closed *and* loudly, never truncate what you are about to inspect or parse, and make degradation a distinct, metered state. [rules/10](rules/10-silent-control-failure.md) is the full catalog. 7. **Read a guard's history before changing it.** Before editing code that validates, escapes, authorises, bounds or rate-limits, find why it is there: `git log -L <start>,<end>:<file>` or `git log -S'<guard expression>'` on the guard lines (`--follow` tracks renames only, not a guard moved between files), plus the project's advisories. A guard that looks redundant can be a past fix. **Check `git rev-parse --is-shallow-repository` first**: a shallow clone (CI and agent sandboxes often are) hides the commit that added the guard, and an empty history is not "no reason for this check". 8. **Finish with the file's audit checklist.** Before declaring code complete, run the relevant rules files' end-of-file checklists against your own diff; fix every "no".

AUDIT mode — hunting vulnerabilities against these rules

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

Process: 1. **Map the attack surface**: entry points (routes, GraphQL resolvers, queue consumers, cron jobs, WS/gRPC, webhooks, file ingestion, LLM tool loops), secrets locations, authz enforcement points, outbound fetchers. Read the **framework's side too** — its security configuration, the middleware chain and the base classes handlers inherit from — because much enforcement (and much of its absence) lives there, not in application code. Where the built-in authorization component cannot express a requirement, expect explicit custom logic; its absence is a finding. OWASP: Authorization Cheat Sheet, Code Review Guide v2. 2. **Sweep by rules file**, prioritized: 03 (authz) and 01 (injection) find the most criticals; then 02 (+17 sessions/tokens), 05 (+20 headers, 21 uploads), 08 (+23 LLM supply chain), 04 (+22 constant time), 07,