Skill: security-checklists

This skill is the depth library behind the security-reviewer agent. The reviewer's body carries the universal method (the three-bucket delegation rule, load-context-first, the always-on STRIDE + LINDDUN open pass, the established-helper-bypass meta-check, the severity rubric, the honest-limits footer, the output format). The shape-specific depth — what to actually check at each trust boundary — lives here, in the per-boundary references/<module>.md modules, so the agent prompt stays lean and the depth scales without bloat.

Reliability-vs-security carve. This library owns security config; the reliability / ops side of infrastructure (idempotent convergence, blast radius, environment isolation, cost/teardown, drift/rollback, observability/smoke) lives in the operational-safety skill, consumed by quality-engineer. The routing splits IaC-security → config-misconfig, IaC-reliability → operational-safety. The two are complementary lenses on the same infra diff — keep the split clean both ways.

How it loads (orchestrator-driven, not self-discovered)

The orchestrator drives loading; the subagent does not. There is no mechanism to force a subagent to invoke a skill, skill discovery is model-invoked and adapter-variable, and the security-reviewer's tools: list does not even include a Skill tool. So depth must not depend on the reviewer finding this library itself.

Concretely, at the work-loop's security-review step (and at the pre-EXECUTE spec-stage pass), the orchestrator:

1. Detects which trust boundaries the diff or spec crosses.
2. Loads only the matching modules via the deterministic boundary→module routing authority — this skill's Module index below (the work-loop security-review bullets dispatch against it rather than carrying their own copy).
3. Inlines the selected modules' content into the security-reviewer subagent's brief — so the reviewer receives a focused ~30-item checklist as prompt text, never a path to resolve.

Where an adapter does support subagent skill auto-discovery, that is a redundant convenience layered on top — never the load-bearing mechanism.

The three-bucket delegation legend

Every check in every module is tagged so the reviewer knows who owns it:

• tool — scanner-owned. Confirm the scanner is wired; don't re-check by hand. Detect the ecosystem's scanner rather than assuming one: npm audit / pip-audit / govulncheck / cargo audit / bundler-audit, or Snyk / Semgrep / CodeQL. If the delegated scanner is absent, do not silently skip (Tier-1 declare/detect/fail-clean): either reason the class best-effort and flag it degraded: no scanner, or state the gap explicitly ("class X is normally scanner-owned; none detected → wire one or accept the gap"). A silent skip is the worst outcome — it looks like coverage.
• hybrid — the scanner finds the flow; you judge the fix. Taint analysis can point at a sink, but whether the escaping, the confinement, or the safe-loader choice is correct is reasoning work.
• reason — reviewer-only. Logic-flaw access control, fail-open vs fail-closed, confused-deputy, privacy exposure — the classes scanners structurally cannot see. The highest-value findings live here.

Established-helper bypass (the repo-aware meta-check)

For each boundary the change crosses, the most actionable real-world finding is "this code rolled its own instead of the repo's blessed helper." Each module names, in generic terms, the kind of helper that boundary usually has. To resolve the repo's actual helper, the reviewer consults, in precedence: the AGENTS.md "blessed security tools/helpers" list → CONVENTIONS.md and any context other packs install (steering files, etc.) → inference fallback (grep the codebase for the de-facto helper). Flag code that re-implements a boundary the repo already has a sanctioned helper for. This skill carries the mechanism only — never any one repo's specific helper names.

Module index

This index is the deterministic boundary→module routing authority — the work-loop security-review bullets (diff-stage and the pre-EXECUTE spec-stage pass) dispatch against the Boundary column rather than carrying their own copy. Match the trust boundary the change crosses to its module(s); the config-misconfig row's IaC / deploy-config entry is the same one the work-loop infra-flavored signal keys on.

Module	Boundary (the change crosses)	Primary anchor
access-control	authz / object- & function-level access; a new or changed endpoint, handler, RPC	OWASP A01:2025 + API Security Top 10:2023 (BOLA/BFLA)
authn-session	authentication, session, login, password, MFA, tokens (JWT / API key)	OWASP A07:2025 + ASVS 5.0 V6/V7
injection	untrusted input → interpreter / deserializer (SQL / shell / template / LDAP / HTML; deserialization)	OWASP A05:2025 (+ A08 deserialization)
path-and-file	filesystem path from input, file upload, archive extraction	CWE-22 / CWE-73 + ASVS 5.0 V12
secrets-and-crypto	secrets, keys, hashing, signing, crypto, randomness	OWASP A04:2025 + ASVS 5.0 V11
outbound-ssrf	outbound HTTP / DNS / URL fetch, webhooks	OWASP A01:2025 (SSRF) + ASVS 5.0 V13
supply-chain	dependency / lockfile / manifest change, build-artifact fetch (build trust)	OWASP A03:2025 (new)
config-misconfig	CORS, IAM, IaC, server / framework / deploy config	OWASP A02:2025
exceptional-conditions	error handling, retries, fallbacks, fail-open paths	OWASP A10:2025 (new) (+ A09 logging)
llm-agent	prompts, model / tool exposure, MCP, model-output handling, agentic action	OWASP LLM Top 10:2025 + OWASP Top 10 for Agentic Applications:2026

Threat modeling (STRIDE + LINDDUN for privacy) and design-time Insecure Design (A06 / Proactive Controls 2024) are not runtime modules: STRIDE + LINDDUN ride the always-on open pass in the agent body, and Insecure Design is realized by the spec-stage secure-design mode. Each module below carries a Spec-stage section so the same depth backs the design-time pass in its proactive-control framing.