ry-sec-review

name: ry-sec-review description: "Секьюрити ревью ry-sec-review: threat model, authz, secrets, vulnerabilities. Используй для: security review. EN: defensive review."

Purpose

Run a high-quality defensive security review of the current implementation. This is not a general code review and not a blocking policy gate by default. It produces evidence-based findings and comments so the agent can decide what to fix immediately and what to report as follow-up.

User-facing reports are written in Russian unless the user asks otherwise. Code, paths, symbols, vulnerability categories, and references stay exact.

Auto Invocation

Use this skill without waiting for an explicit $ry-sec-review call when the request asks to:

Review security, vulnerabilities, exploitability, OWASP/ASVS coverage, hardening, or secure implementation quality.
Audit a diff, pull request, feature, full implementation, module, route, endpoint, API, auth/authz flow, admin path, file handler, webhook, parser, dependency, or configuration.
Check secrets, credentials, tokens, crypto, injection, access control, SSRF-like external requests, unsafe deserialization, supply chain, logging, or exceptional conditions.
Produce findings, confidence ranking, remediation, and verification steps.

Do not use this skill for ordinary implementation unless the user asks for security review or the change is high-risk enough to require a focused audit. For lightweight secure-coding comments during implementation, use owasp-top-10-implementation.

Review Style

Use a Mythos-inspired review style without copying unsafe behavior:

Hypothesis-driven: generate concrete "what could go wrong" hypotheses from entry points, trust boundaries, data flows, and changed files.
Variant-aware: look for repeated root causes, sibling bugs, and near-miss patterns across the codebase.
Evidence-first: confirm findings through code paths, configs, tests, and reachable source-to-sink flows.
Confidence-ranked: separate confirmed vulnerabilities from plausible risks and hardening suggestions.
Defensive-only: do not produce weaponized exploit code, stealth steps, persistence, credential extraction, or destructive commands.

Inputs To Establish

Before reviewing, determine:

Scope: full repo, current diff, PR branch, specific files, feature, or module.
Assets: protected data, money movement, admin capability, tenant/user boundaries, secrets, credentials, tokens, files, jobs, webhooks, AI outputs.
Entry points: routes, controllers, CLI commands, background jobs, webhooks, queues, public components, MCP tools, file parsers, config loaders.
Trust boundaries: browser/server, user/admin, tenant/tenant, internal/external service, local/remote file, generated/manual code.
Security controls: authn, authz, validation, encoding, rate limiting, logging, error handling, crypto, dependency controls.

If scope is unclear, make a reasonable assumption and state it. Do not stop unless the review cannot be bounded safely.

Review Workflow

Recon: map changed files, entry points, dependencies, configuration, privileged operations, and data flows. Use Serena first when available: get_symbols_overview, targeted find_symbol, find_referencing_symbols, and search_for_pattern.
Baseline scan: use available automated help when useful, especially local project security scripts and CI security artifacts, but do not rely on scanners as the only evidence.
Hypothesize: generate review hypotheses mapped to OWASP Top 10 2025, ASVS 5.0.0 concepts, and project-specific threat boundaries.
Trace: prove or reject each high-risk hypothesis by following source-to-sink paths, authorization checks, validation, output handling, config, and error paths.
Variant hunt: search for similar patterns in sibling files, repeated helpers, copied logic, shared middleware, and framework-specific conventions.
Assess: rank by severity, exploitability, reachability, business impact, and confidence. Prefer fewer high-confidence findings over broad speculation.
Remediate: propose precise fixes, tests, and verification commands. When asked to implement, fix confirmed issues in scope.
Report: findings first, then residual risks and verification status.

OWASP Review Coverage

Review against:

A01 Broken Access Control: missing server-side authorization, IDOR/BOLA, tenant boundary bypass, admin route exposure, confused deputy.
A02 Security Misconfiguration: debug exposure, permissive CORS, missing headers, unsafe cloud/IaC defaults, exposed credentials/config.
A03 Software Supply Chain Failures: vulnerable dependencies, untrusted scripts, unsigned artifacts, unpinned images/actions, typosquatting risk.
A04 Cryptographic Failures: weak crypto, bad randomness, plaintext sensitive data, key misuse, token storage and transport issues.
A05 Injection: SQL/NoSQL/LDAP/template/command injection, unsafe eval, shell interpolation, unsafe deserialization.
A06 Insecure Design: race conditions, business logic abuse, missing abuse controls, replay, quota/rate limit bypass, unsafe workflow assumptions.
A07 Authentication Failures: weak reset/login/session/token flow, MFA bypass, session fixation, missing re-auth for sensitive operations.
A08 Software or Data Integrity Failures: mass assignment, unsafe update/webhook handling, unverified signed data, trusted client-controlled state.
A09 Security Logging and Alerting Failures: missing audit trail, sensitive logs, lack of alertable authz/authn/security events.
A10 Mishandling of Exceptional Conditions: fail-open errors, leaked stack traces/secrets, inconsistent rollback, exception path bypass.

Also check AI/LLM surfaces when present: prompt injection, tool injection, data exfiltration through model output, untrusted tool arguments, unsafe generated code execution, and cost/resource abuse.

Finding Format

Findings must come first and be ordered by severity.

Use this format:

- Severity: Critical | High | Medium | Low | Info
  Category: OWASP/ASVS/security class
  Confidence: 0-100
  Location: `path:line` or `symbol`
  Evidence: concrete code/config behavior proving the issue
  Attack path: high-level defensive explanation without weaponized steps
  Impact: what can go wrong
  Fix: precise remediation
  Verification: exact test, command, or manual check

If no findings are found, state that explicitly and list residual risks or untested areas.

Severity Guidance

Critical: remote unauthenticated compromise, auth bypass, credential/secret exposure with high impact, arbitrary command execution, cross-tenant data compromise, or destructive data loss.
High: confirmed authorization bypass, exploitable injection, sensitive data exposure, dangerous misconfiguration, supply-chain risk with reachable execution, or exploitable business logic flaw.
Medium: reachable weakness requiring constraints, defense bypass with limited impact, missing security control that materially increases risk, or likely variant with strong evidence.
Low: hardening issue, missing best-practice control, low-impact information disclosure, or incomplete logging without direct exploit path.
Info: architecture note, verification gap, or secure default recommendation.

Safety Rules

Do not provide exploit payloads, malware behavior, stealth/persistence instructions, credential extraction steps, or destructive commands. For explicit destructive requests such as deleting protected paths with rm -rf, follow Codex safety and approval rules.

Use harmless proof only when necessary: describe the condition, test expectation, and safe reproduction shape without weaponizing it.

Do not report secrets verbatim. If a secret-like value is found, redact it and identify only the file path, variable name, and exposure class.

Output

For a standalone review, answer in Russian with:

Findings: ordered by severity using the finding format.
Rejected hypotheses: important high-risk hypotheses that were checked and rejected, with brief evidence.
Residual risks: untested areas, missing runtime context, or scanner gaps.
Verification: commands/tools run and what they proved.
Recommended fixes: immediate fixes and optional hardening.

For implementation-after-review, keep the final concise: fixed findings, checks run, and remaining risk.