SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillssota-code-security

sota-code-security

Security & auditing

View repository

Updated 10-16 00:06

About this skill

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, rules/17 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. 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

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, 06, then 09, 18 and 19; 10 (silent no-ops) is step 5's 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 — rules/16 is the catalogue of shapes, rules/14 the control not in force, rules/13 the context-dependent classes, rules/12 the mutation probe that proves one. 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. Absence claims ("no instances of X") need a wider search and a second method than presence claims do.

Severity conventions (CVSS-style impact mapping)

Severity CVSS band Criteria Examples
Critical 9.0–10.0 Unauthenticated (or trivially authenticated) remote compromise of confidentiality/integrity at scale: RCE, SQLi dumping the DB, auth bypass, cross-tenant read/write, secrets in public repo/client bundle pickle.loads(request.body); JWT alg not pinned; reflected-Origin CORS with credentials; tenant_id from request param
High 7.0–8.9 Single-user-scoped compromise or privileged-precondition full compromise: IDOR on sensitive objects, stored XSS, SSRF reaching metadata, authenticated command injection, session fixation, missing object-level authz Ownership check missing on GET /documents/{id}; dangerouslySetInnerHTML on user bio; upload served executable from app origin
Medium 4.0–6.9 Meaningful weakening requiring chaining or limited impact: CSRF on non-critical state, ReDoS/resource exhaustion, missing rate limit on login, verbose errors leaking internals, weak-parameter argon2/bcrypt, missing security headers on sensitive pages, log injection No lockout on login; stack traces in prod 500s; SameSite unset with no CSRF token but Origin checked
Low 0.1–3.9 Hardening gaps and defense-in-depth misses with no direct exploit: missing __Host- prefix, Server header exposure, report-only CSP, unmasked PII in internal logs, missing Vary: Origin Cookie lacks prefix; HSTS missing includeSubDomains; EXIF not stripped

Adjust one band up/down for context: data sensitivity (health/financial ↑), internet-exposed vs internal-only (↓ one max — network position is not identity), existing compensating control (↓), trivially scriptable at scale (↑). A compensating control lowers the band; it never closes the finding as won't-fix — the defect still gets fixed, because the control in front of it can be changed, removed or bypassed later. OWASP: Code Review Guide v2.

Finding format

[SEVERITY] <title>
File: <path>:<line>            (every claim anchored to file:line)
CWE: CWE-<id> (<name>)         (omit only if genuinely unmapped)
Source → Sink: <where attacker data enters> → <dangerous operation>
Exploit scenario: <concrete attacker story: who, sends what, gets what>
Fix: <specific change, referencing the rules/ section with the pattern>

Order the report Critical→Low; lead with a one-paragraph executive summary (counts by severity, worst finding, systemic themes). Group repeated instances of one weakness into a single finding listing all locations.

Rules index

File Topics Read this when...
rules/01-input-injection.md SQLi/NoSQLi, command & argument injection, path traversal/Zip Slip, SSRF + DNS rebinding, XXE, XML built from strings (CWE-91), SSTI, deserialization, prototype pollution, ReDoS, canonicalization, allowlist validation ...any external data reaches a query, shell, path, URL fetcher, parser, template, regex, or object loader; writing input validation; auditing any handler
rules/02-authentication.md argon2id parameters, credential-stuffing defense, OAuth2/OIDC + PKCE, MFA/TOTP, account recovery, passkeys/WebAuthn, LDAP bind as login (empty password = unauthenticated bind); transaction authorization — what you see is what you sign, step-up that cannot be downgraded (§5.1) ...building or reviewing login, signup, SSO, password reset, MFA enrollment, directory (LDAP/AD) login, or anything that proves identity
rules/03-authorization.md Deny-by-default enforcement, IDOR/BOLA, function-level authz, RBAC/ABAC/ReBAC, multi-tenant isolation (RLS), confused deputy, authz bypass patterns ...any endpoint takes an object ID; multi-tenant features; role/permission systems; service-to-service trust; hunting access-control bugs (start here for audits)
rules/04-cryptography.md Algorithm table (AEAD, X25519, Ed25519), nonce discipline, CSPRNG use, key management/rotation/KMS, TLS config & cert verification, secrets in code/CI (constant-time comparison moved to rules/22); key agreement — validate and authenticate the peer key (§1.1) ...encrypting, signing, hashing, generating tokens, configuring TLS, storing secrets, or you see any crypto primitive or verify=False in code; constant time as a property of the emitted code (§6.1) — secret-dependent division, strength reduction as an optimiser courtesy, the arch × -O matrix — now rules/22 §1.1
rules/05-web-security.md Context-aware XSS encoding, Trusted Types, nonce-based CSP, CSRF stack, CORS misconfig, clickjacking, header baseline, cookie attributes/prefixes (the file upload pipeline moved to rules/21) ...rendering user content, setting headers/cookies, configuring CORS, or auditing anything browser-facing (uploads: rules/21)
rules/06-memory-resource-safety.md Integer overflow/truncation, bounds & banned C APIs, unsafe/FFI policy, native library search paths (DLL planting, CWE-427), untrusted size fields, decompression bombs, timeouts/rate limits/load shedding, TOCTOU & race-driven bypass, temp files ...parsing binary formats, doing arithmetic on input-derived sizes/money, writing C/C++/unsafe Rust/FFI or loading a native library, or auditing DoS and concurrency surfaces
rules/07-data-exposure.md Leak-free error handling, oracle-free responses, logging redaction & log injection, security event logging, mass assignment, response over-exposure, debug surfaces in prod; named security events and in-app detection points (§2.1) ...designing errors/logging, binding request bodies to models, shaping API responses, or auditing what an attacker learns from outputs
rules/08-llm-ai-security.md Prompt injection (direct/indirect), lethal trifecta, dual-LLM/taint gating, tool-call authorization & human-in-the-loop, model output as untrusted data, RAG ACLs; messages between agents and between agents and tools: authentication, schema, replay, delegation (§1a); model supply chain, MCP servers and prompt logging moved to rules/23 ...building or auditing anything with an LLM: agents, tool calling, RAG, chat UIs rendering model output, MCP servers, prompt/completion logging
rules/09-untrusted-data-ingestion.md Hostile data feeds/content; ingest as a trust boundary, provenance/taint tagging; sandboxed parsers (image/archive/PDF/Office/XML/CSV/JSON, fuzzy-hash); zip-slip/zip-bomb/pixel-bomb/decompression caps; size/rate/timeout DoS controls, quarantine/DLQ; parse-don't-validate, MIME sniffing, polyglots, AV; feed integrity & broker pattern ...ingesting attacker-authored external data — threat-intel/RSS feeds, scraped content, user uploads, third-party webhooks/APIs, RAG corpora, email, file imports — through parsers into storage/UI; auditing collectors, upload endpoints, or feed pipelines
rules/10-silent-control-failure.md Controls that look enabled and do nothing: the falsification question, weak existence checks, optional-dependency degradation, empty/placeholder rulesets, swallowed enforcement exceptions, overloaded flags, early-return and truncation bypasses (into an inspector or out of a generator), silently-ignored config keys, doc/code default drift, unearned claims in output — the numbers and the verification words (verified/reachable/tainted, severity from a constant), shipped-artifact gaps, prompt/instruction standing in for an enforced control (attention leakage), a gate whose trigger never fires (a skipped job reports Success), a control parked in audit/warn/dry-run/report-only mode; the degraded-control helper; absence-claim evidence (the mutation probe itself moved to rules/12) ...you are about to trust that a control is working — any audit pass over controls that exist, any build where a safeguard's failure would be invisible, any "it's enabled" claim from a banner, config, or green test
rules/11-dead-path-diagnostics.md Finding the above at codebase scale: duration-not-result, printing every gate's denominator (0 checked, 0 failed, exit 0), cross-scale delta, telemetry silence, the provenance of an analysis's rows — a sink that tests and production both write is two populations, and the contaminated aggregate carries the larger n, proving a fix executed; scale-dependent silence (unbounded traversal, size-gated paths fixtures never cross, budgets that truncate coverage silently); stale-artifact no-ops (a cache/tag key narrower than the behaviour); format assumptions from one sample + lenient parsers returning plausible-but-wrong values; contract drift by interaction — the producer/consumer seam no schema declares; location-dependent silence — a filter matching the ambient environment (absolute path, hostname) so a collection is correct on one machine and empty on another; asserts stripped by -O/NDEBUG/missing -ea; ACTIVE/LATENT/REFUTED evidence labels; running every CI/hook/runbook script before reading any of them; the four-state watcher model (DONE / NOT-DONE / GONE / UNKNOWN — GONE is terminal and knowable, and is the row people delete while fixing the other bug), metamorphic liveness oracles for a tool whose correct output you cannot state (the test oracle problem); closes by handing the tools that produced the findings to rules/15 ...sweeping a whole system for stages that report success while doing nothing, deciding where to apply rules/10, or validating that a pipeline's "0 findings" means it ran
rules/12-verifying-the-verifier.md Proving a specific control works: the mutation probe — including its commonest failure, a substitution that matched nothing, and asserting the pattern is present BEFORE writing — (no-op the body, watch what fails) with its two traps — a path skipped for an unrelated reason, and a mutation that never landed; the allow arm, because a control that blocks everything reads as one that works; and where the probe lives — a --self-test mode of the tool over a harness beside it, so "every check can go red" is a property of the suite, not of whoever last edited it; the control that was correct and then edited — detection is bounded by the integrity of the detector, manifesting the verifier is necessary and not sufficient, and the fix is location (execute from a copy the constrained principal cannot write to), plus the protocol-level residual where "allow" is silence; the cross-discipline lineage (proof test, positive control, BITE, poka-yoke) ...whenever you add or review a control and need to know whether anything holds it in place
rules/15-instruments-and-guards.md The guard that correctly declines and says nothing — a conjunction discards which reason applied (§3a) · The instrument you wrote ninety seconds ago — during verification the harness is newer than the subject, so the prior belongs on it, and the tell is an implausible result rather than a red one (§2.1) · Distrusting whatever did the proving. Your instrument is a control — scorers, gates, benchmarks and thresholds need a known-bad at the floor and a known-good at the ceiling in CI, a negative control, abort-don't-warn, sample-before-counting, and validation on inputs that can fail; the five instrument-specific failure modes; instruments that run over time (the four watcher states, incl. GONE); evidence the subject supplies about itself; disclosing an instrument changed after results were seen; and the guard that is an instance of what it guards — a predicate the defect satisfies ("auth=" in line passes on auth=None), a guard nested in another gate's success branch, a denominator counting only survivors, per-target kill verification at 100% ...after rules/10 and rules/11 have produced findings, before any is reported or any number quoted; whenever you write something whose output decides whether something else is OK
rules/16-where-no-ops-hide.md The catalogue split out of rules/10 (ROADMAP 55): sixteen shapes a control takes when it is present, looks enabled and enforces nothing — weak existence checks, degraded optional dependencies, swallowed exceptions on the enforcement path, truncation into an inspector, the control that is not in force, a flag that parses but does nothing, the aggregate that masks a detection. Section numbers unchanged across the move, so rules/10 §2.7 is now rules/16 §2.7. Read rules/10 first — that is the method, this is what it finds
rules/17-sessions-and-tokens.md Server-side session lifecycle and fixation, idle/absolute timeouts and revoke-all, remember-me (selector/validator), JWT verification (algorithm allowlist, claims), token lifetimes, refresh rotation with reuse detection, token storage (split out of rules/02, keeping its section numbers 2 and 3) ...building or reviewing sessions, cookies that carry them, JWTs or refresh tokens
rules/18-tamper-evident-logs.md Tamper-evident logs and audit ledgers: keyed chains vs bare hash chains, external anchoring, integrity vs completeness, segmented ledgers (formerly rules/04 section 8, now §1) ...building or auditing anything claiming "tamper-evident", "audit-grade" or "immutable" records
rules/19-anti-automation-and-abuse.md Automated abuse that is neither volumetric DoS nor injection: fake signups and multi-accounting, credential-stuffing responses, CAPTCHA and proof-of-work challenges, and business flows that hand out value (coupons, referrals, trials, scarce inventory, card payments) — OWASP OAT, CWE-799/837 ...building or reviewing signup, login, checkout, promotions, referrals or anything a bot can farm
rules/20-browser-response-hardening.md How security headers reach the browser (every status code, exactly once), HSTS rollout and preloading, a Fetch Metadata resource isolation policy against XS-Leaks, stripping diagnostic headers infrastructure adds; the header baseline, CSP, CSRF, CORS and cookies stay in rules/05 ...configuring response headers at the app, proxy or CDN, or auditing what a browser actually receives
rules/21-file-uploads.md The file upload pipeline: content validation over extension trust, server-side renaming, non-executable storage on a separate origin, size caps before buffering, SVG handling (split out of rules/05, formerly section 10, now §1) ...accepting, storing or serving any user-uploaded file
rules/22-constant-time-comparison.md Constant-time comparison of secrets (tokens, MACs, OTPs) and constant time as a property of the emitted code (§1.1) — secret-dependent division, strength reduction, the arch × -O matrix (split out of rules/04, formerly section 6) ...comparing any secret, or claiming a routine is constant-time
rules/23-llm-platform-supply-chain.md Models, weights and adapters as executable dependencies, prompts and guardrail configs as security-relevant code, MCP server supply chain past the pin, named MCP/agent attack classes, prompt and completion logging (split out of rules/08, formerly section 5, now §1) ...installing a model or MCP server, versioning prompts or guardrails, or logging model traffic
rules/13-context-dependent-silence.md The five classes rules/10 does not cover, split out of rules/11 §3 — each one correct under the condition you tested and silently wrong under the one you shipped into: scale-dependent silence (a size-gated path no fixture crosses), the stale-artifact no-op (a cache key narrower than the behaviour), a format assumption generalised from one sample, contract drift at a seam neither side declared — including the seam whose producer is a model, where the defaulted read .get(k, default) turns a key-name disagreement into a plausible constant and only a runtime unconsumed-key diff can close it — and location-dependent silence (correct here, empty there) ...a diagnostic from rules/11 §2 fired — a suspicious duration, a denominator that will not move, telemetry that went quiet — and you need the class behind it; also before trusting any result measured in one environment, at one scale, against one sample
rules/14-control-not-in-force.md The other half of rules/10: not a control that runs and does nothing, but one that is not there — unearned claims in reporting output (the numbers and the verification words), shipped-artifact gaps, a natural-language instruction standing in for an enforced control, a control that never executes (a skipped job reports Success), and one parked in audit/warn/dry-run/report-only mode ...you have read the control's body and it looks right; these are found by asking what ships, what fires, and what the output is entitled to say — never by reading the control itself; the stage that reports success is not the stage that failed (§4b) — discovery vs collection, and proving a repair by output delta rather than a green light

Top-10 non-negotiables

Violations of these are findings regardless of context; in BUILD mode they are never acceptable shortcuts:

  1. Every SQL/NoSQL value parameterized — no string-built queries, raw-query escape hatches audited, identifiers allowlist-mapped. (CWE-89)
  2. No shell string execution — argv arrays only, -- separators, no shell=True/exec(string). (CWE-78)
  3. No native deserialization of untrusted data — no pickle / ObjectInputStream / unserialize / Marshal / yaml.load; data-only formats + schema. (CWE-502)
  4. Object-level authz on every ID the client supplies — ownership/tenant predicate inside the query, deny by default, 404 for unauthorized. (CWE-639/862)
  5. Passwords only as argon2id (or scrypt/bcrypt) hashes at current parameters; login/reset rate-limited with uniform errors. (CWE-916/307)
  6. JWT verification pins algorithms and checks exp/iss/aud; OAuth is Authorization Code + PKCE with exact redirect URIs; tokens never in localStorage or URLs. (CWE-347)
  7. No hardcoded or client-shipped secrets, no disabled TLS verification — CSPRNG for all tokens, constant-time comparison for all secret checks. (CWE-798/295/330/208)
  8. All user-influenced output encoded/sanitized for its sink — HTML context encoding + allowlist sanitizer for rich text; applies equally to LLM output. (CWE-79)
  9. Outbound fetch of user-supplied URLs gets full SSRF defense — scheme allowlist, post-resolution private-IP block, pinned connection, redirect re-validation. (CWE-918)
  10. LLM tool calls authorized in code against the human principal — session-bound scoping, schema-validated arguments, human confirmation for irreversible actions; prompts are never the security boundary. (CWE-863)