| name | security-checklists |
| description | Progressive-disclosure security-depth modules for the security-reviewer. Holds ten boundary-keyed checklists (access-control, authn-session, injection, path-and-file, secrets-and-crypto, outbound-ssrf, supply-chain, config-misconfig, exceptional-conditions, llm-agent) as references/, each anchored on a current standard (OWASP Top 10:2025, ASVS 5.0, API Security Top 10:2023, Proactive Controls 2024, CWE Top 25, OWASP LLM Top 10:2025). The work-loop's orchestrator loads only the boundary-matching modules and inlines them into the security-reviewer's brief; the subagent never self-discovers this skill. Not a reviewer prompt itself — it is the depth library the reviewer reasons from. |
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 ten references/<module>.md
modules, so the agent prompt stays lean and the depth scales without bloat.
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:
- Detects which trust boundaries the diff or spec crosses.
- Loads only the matching modules via the deterministic
boundary→module routing table in
work-loop/SKILL.md.
- 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
| Module | Boundary | Primary anchor |
|---|
access-control | authz / object- & function-level access | OWASP A01:2025 + API Security Top 10:2023 (BOLA/BFLA) |
authn-session | authentication, session, tokens | OWASP A07:2025 + ASVS 5.0 V6/V7 |
injection | untrusted input → interpreter / deserializer | OWASP A05:2025 (+ A08 deserialization) |
path-and-file | filesystem paths, uploads, archive extraction | CWE-22 / CWE-73 + ASVS 5.0 V12 |
secrets-and-crypto | secrets, keys, hashing, signing, 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 | dependencies, lockfiles, build trust | OWASP A03:2025 (new) |
config-misconfig | CORS, IAM, IaC, server config | OWASP A02:2025 |
exceptional-conditions | error paths, retries, fail-open | OWASP A10:2025 (new) (+ A09 logging) |
llm-agent | prompts, tool exposure, MCP, model output | OWASP LLM Top 10:2025 |
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.
