sota-code-securitylisted
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.
martinholovsky/SOTA-skills · ★ 19 · AI & Automation · score 78
Install: claude install-skill martinholovsky/SOTA-skills
# 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. **Struc