/sota-code-security

name: sota-code-security
description: >-
  Secure coding and security auditing rules (2026 baseline). 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. 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 and rules/04. 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 is the full catalog. 7. **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

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. 2. **Sweep by rules file**, prioritized: 03 (authz) and 01 (injection) find the most criticals; then 02, 05, 08, 04, 07, 06, and 10 (silent no-ops) as a pass over whatever the others confirmed exists. For each file, grep-drive the hunt from its named sinks/APIs (e.g. `shell=True`, `dangerouslySetInnerHTML`, `verify=False`, `pickle.loads`, `merge(`, `Object.assign(.*req.body`, `permit!`, `algorithms=` absent near `jwt.`). 3. **Trace, don't pattern-match**: confirm untrusted data actually reaches the sink and no upstream boundary neutralizes it. Report the full source→sink path. A reachable sink with attacker data = finding; an unreachable one = note as hardening debt, Low. 4. **Check the negatives**: missing controls are findings too — absent rate limiting, absent CSRF tokens, absent tenant predicate, absent timeout, absent security headers. Use each rules file's audit checklist as the completeness gate; every "no" answer becomes a finding or an accepted risk. 5. **Check the inert**: a control that is *present* but does nothing is invisible to steps 2–4, because the code is not wrong — it is a no-op. Run rules/10 as its own pass over every control the sweep confirmed exists: swallowed exceptions, weak existence checks, truncation into an inspector or out of a generator, degradation that never logs, and tests that pass against a no-op'd body. Sweep with rules/11 to decide where to look, then close with **rules/15** on the tools that produced your findings — an unvalidated instrument has produced none. 6. **Verify, then report.** No speculative findings: state the concrete exploit scenario; if exploitability is uncertain, say what's unverified and rate conservatively. Ab