SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsreview-security

review-security

Security & auditing

View repository

Updated 10-16 01:35

About this skill

Skill: Review security

Purpose

Only review code for security issues. Do not define scope (diff vs codebase) or perform language/framework/architecture analysis; these are separate atomic skills. Emit a standard-formatfindings listfor aggregation. Focus on injection (SQL, command, template), sensitive data and logging, authentication and authorization, dependencies and CVEs, configuration and secrets, and encryption and hashing.

Core Objective

Primary objective: produce a security-focused findings list covering injection, sensitive data, authentication/authorization, dependencies, configuration, and encryption for the given code scope.

Success criteria(all requirements must be met):

  1. ✅ Security-only scope: only the security dimension is reviewed; no scope selection, language/framework conventions, or architecture analysis is performed
  2. ✅ Covers all six categories: evaluates injection, sensitive data/logging, authentication/authorization, dependencies/CVEs, configuration/secrets, and cryptography where relevant
  3. ✅ Conforms to the findings format: each finding includes location, category ("cognitive-security"), severity, title, description, and optional recommendation
  4. ✅ Flags critical issues: clear vulnerabilities (e.g., hardcoded secrets, SQL injection) are flagged as "critical" severity
  5. ✅ Actionable output: each finding has a specific location reference and a concrete remediation or improvement recommendation

AcceptanceTest: Does the output contain a standard-format findings list covering all relevant security dimensions, with critical vulnerabilities clearly flagged and actionable recommendations provided?

Scope boundaries (Scope boundaries)

This skill is responsible for：

  • Injection vulnerabilities (SQL, command, template, path traversal)
  • Sensitive data exposure in logs, responses, or client-side storage
  • Authentication and authorization weaknesses (authentication bypass, IDOR, CSRF, session handling)
  • Dependency vulnerabilities and CVE assessment
  • Configuration and secret management issues
  • Cryptographic weaknesses and key management issues

This skill is not responsible for：

  • Scope selection (deciding which files/paths to analyze) — scope is provided by the caller
  • Language/framework convention analysis — use "review-dotnet", "review-java", "review-go", etc.
  • Architecture analysis — use "review-architecture"
  • Performance analysis — use "review-performance"
  • SQL-specific deep review (use "review-sql" for comprehensive SQL analysis)
  • Full orchestrated review — use "review code"

Handoff point: after emitting all security findings, hand them off to the "review code" orchestrator to aggregate with other cognitive findings, or deliver them directly to the user for a security-focused review session.

Usage scenarios (Use cases)

  • Orchestrated review: used as the cognitive step whenorchestrate-code-reviewruns scope→language→framework→library→cognitive.
  • Security-focused review: when the user only wants to check the security dimension (e.g., before a release or audit).
  • Compliance or audit: Output as a documented, repeatable security checklist.

When to Use: When the task includes a security audit. The scope and code scope are determined by the caller or user.

Behavior (Behavior)

The scope of this skill

  • Analyze：the security dimensions in the given code scope(files or diffs provided by the caller). Do not decide the scope; accept the code scope as input.
  • Do not: perform scope selection, language/framework conventions, or architecture review. Focus only on security.

Review Checklist (Security Dimensions Only)

  1. Injection: SQL injection (parameterization, raw queries); command injection (shell, exec); template injection (user-controlled templates); path traversal; related LDAP/XML injection.
  2. Sensitive Data and Logging: secrets, tokens, or PII in logs or error messages; sensitive data in URLs or client-side storage; exposure in responses or caches.
  3. Authentication and Authorization: missing or weak authentication; broken access control (IDOR, privilege escalation); session handling and CSRF; permission checks for every sensitive operation.
  4. Dependencies and CVEs: known vulnerable dependencies (versions, advisories); unpinned or overly broad version ranges; supply chain and integrity.
  5. Configuration and Secrets: hardcoded secrets; secrets in configuration files or environments; secure default configuration; feature flags and debug modes in production.
  6. Cryptography and Hashing: weak or deprecated algorithms (e.g., MD5, SHA1 for security); improper cryptographic usage; key management and storage; password hashing (e.g., bcrypt, Argon2).

Tone and References

  • Professional and technical: reference specific locations (file:line). Emit findings containing location, category, severity, title, description, recommendation. Use severity for obvious vulnerabilities.

Input & Output (Input & Output)

Input (Input)

  • Code scope: the files or directories (or diff) already selected by the user or scope skill. This skill does not decide the scope; it reviews only the provided code for security purposes.

Output (Output)

  • Emit zero or moreAppendix: Output Contractin the format defined infindings。
  • The category of this skill iscognitive-security。

Limitations (Limitations)

Hard Boundaries (Hard Boundaries)

  • Do notperform scope selection, language, framework, or architecture review. Stay within the security scope.
  • Do notgive conclusions without specific locations or actionable recommendations.
  • Do notassume deployment or network topology unless otherwise stated; focus on the code and configuration within scope.

Skill Boundaries (Skill Boundaries)

Do not do these(other skills can handle them):

  • Do not select or define the code scope (diff vs codebase) — the scope is determined by the caller or "review code"
  • Do not perform language/framework convention analysis - use review-dotnet、review-java、review-go , etc.
  • Do not perform architecture or performance reviews — use 'review-architecture' or 'review-performance'
  • Do not perform comprehensive SQL analysis — use review-sql

When to Stop and Hand Off：

  • When all security findings are produced, hand them off to 'review-code' for aggregation in a curated review
  • When the user needs a comprehensive review (scope + language + cognitive), redirect to 'review-code'
  • When SQL-specific security issues dominate, suggest also running 'review-sql' for deeper SQL coverage

Self-Check

Core Success Criteria

  • Security scope only: Only review the security dimension; scope selection, language/framework conventions, or architecture analysis are not performed
  • Covers all six categories: Where relevant, evaluate injection, sensitive data/logging, authentication/authorization, dependencies/CVE, configuration/secrets, and cryptography
  • Conforms to the findings format: Each finding includes location, category ('cognitive-security'), severity, title, description, and optional recommendation
  • Critical issues flagged: Obvious vulnerabilities (e.g., hardcoded secrets, SQL injection) are flagged with 'critical' severity
  • Actionable output: Every finding has a specific location reference and concrete remediation or improvement recommendations

Process Quality Checks

  • Was only the security dimension reviewed (no scope/language/architecture)?
  • Are relevant injection, sensitive data, authorization, dependencies, configuration/secrets, and cryptography covered?
  • Does each finding include location, category=cognitive-security, severity, title, description, and optional recommendation?
  • Are critical issues clearly flagged and actionable?

Acceptance Tests

Does the output include a findings list in the standard format, covering all relevant security dimensions, and clearly flag critical vulnerabilities with actionable recommendations?

Examples

Example 1: Hardcoded secret

  • Input: An API key or password in the source code.
  • Expected: Emit a critical finding; recommend environment variables or a secret manager; reference the line. category=cognitive-security.

Example 2: Building SQL from user input

  • Input: A query string constructed by concatenating user-controlled input.
  • Expected: Emit a critical finding for SQL injection; recommend parameterized queries. category=cognitive-security.

Edge case: false positive

  • Input: A placeholder in configuration, such as 'changeme' or 'TODO', not used in production.
  • Expected: Emit a minor/suggestion finding to remove or replace before production; if the context indicates non-production, do not flag as critical. If unclear, ask the user or emit as a suggestion.