Back to Details

review-security

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill: Review Security

Skill：安全审查

Purpose

目标

Review code for security concerns only. Do not define scope (diff vs codebase) or perform language/framework/architecture analysis; those are separate atomic skills. Emit a findings list in the standard format for aggregation. Focus on injection (SQL, command, template), sensitive data and logging, authentication and authorization, dependencies and CVEs, configuration and secrets, and cryptography and hashing.
仅针对安全相关问题审查代码。无需定义审查范围（差异对比 vs 整个代码库），也无需进行语言/框架/架构分析；这些属于独立的原子技能。按照标准格式输出问题发现清单用于汇总。重点关注注入（SQL、命令、模板注入）、敏感数据与日志、身份验证与授权、依赖项与CVE漏洞、配置与密钥、加密与哈希相关内容。

Use Cases

使用场景

  • Orchestrated review: Used as a cognitive step when review-code runs scope → language → framework → library → cognitive.
  • Security-focused review: When the user wants only security dimensions checked (e.g. before release or audit).
  • Compliance or audit: As a repeatable security checklist output for documentation.
When to use: When the task includes security review. Scope and code scope are determined by the caller or user.
  • 编排式审查：作为review-code执行范围→语言→框架→库→认知分析流程中的认知步骤使用。
  • 聚焦安全的审查：当用户仅希望检查安全维度时（例如发布前或审计时）。
  • 合规或审计：作为可重复使用的安全检查清单输出，用于文档记录。
适用时机：当任务包含安全审查时。审查范围由调用者或用户确定。

Behavior

行为规范

Scope of this skill

本技能的审查范围

  • Analyze: Security dimensions in the given code scope (files or diff provided by the caller). Do not decide scope; accept the code range as input.
  • Do not: Perform scope selection, language/framework conventions, or architecture review. Focus only on security.
  • 分析：在给定的代码范围（调用者提供的文件或差异内容）内的安全维度问题。无需自行决定审查范围；接受输入的代码范围即可。
  • 禁止操作：不要进行范围选择、语言/框架规范检查或架构审查。仅聚焦安全问题。

Review checklist (security dimension only)

审查清单（仅安全维度）

  1. Injection: SQL injection (parameterization, raw queries); command injection (shell, exec); template injection (user-controlled templates); path traversal; LDAP/XML injection where relevant.
  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 on 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 config files or environment; secure default configuration; feature flags and debug mode in production.
  6. Cryptography and hashing: Weak or deprecated algorithms (e.g. MD5, SHA1 for security); inappropriate use of encryption; key management and storage; password hashing (e.g. bcrypt, Argon2).
  1. 注入漏洞：SQL注入（参数化、原生查询）；命令注入（shell、exec）；模板注入（用户可控模板）；路径遍历；相关场景下的LDAP/XML注入。
  2. 敏感数据与日志：日志或错误信息中包含密钥、令牌或PII；URL或客户端存储中的敏感数据；响应或缓存中的数据泄露。
  3. 身份验证与授权：缺失或薄弱的身份验证；访问控制失效（IDOR、权限提升）；会话处理与CSRF；每个敏感操作都需进行权限检查。
  4. 依赖项与CVE漏洞：已知存在漏洞的依赖项（版本、安全公告）；未固定或版本范围过宽的依赖；供应链与完整性问题。
  5. 配置与密钥：硬编码密钥；配置文件或环境变量中的密钥；安全默认配置；生产环境中的功能标志与调试模式。
  6. 加密与哈希：弱或已弃用的算法（例如用于安全场景的MD5、SHA1）；加密的不当使用；密钥管理与存储；密码哈希（例如bcrypt、Argon2）。

Tone and references

语气与参考

  • Professional and technical: Reference specific locations (file:line). Emit findings with Location, Category, Severity, Title, Description, Suggestion. Use severity critical for clear vulnerabilities.
  • 专业且技术化：引用具体位置（文件:行号）。输出的问题发现需包含位置、类别、严重程度、标题、描述、建议。明确的漏洞标记为严重（critical）级别。

Input & Output

输入与输出

Input

输入

  • Code scope: Files or directories (or diff) already selected by the user or scope skill. This skill does not decide scope; it reviews the provided code for security only.
  • 代码范围：用户或范围选择技能已选定的文件、目录（或差异内容）。本技能不负责确定范围；仅对提供的代码进行安全审查。

Output

输出

  • Emit zero or more findings in the format defined in Appendix: Output contract.
  • Category for this skill is cognitive-security.
  • 输出零个或多个问题发现，格式遵循附录：输出规范。
  • 本技能的类别为
    cognitive-security
    。

Restrictions

限制条件

  • Do not perform scope selection, language, framework, or architecture review. Stay within security dimensions.
  • Do not give conclusions without specific locations or actionable suggestions.
  • Do not assume deployment or network topology unless stated; focus on code and configuration in scope.
  • 禁止进行范围选择、语言、框架或架构审查。仅聚焦安全维度。
  • 禁止在无具体位置或可操作建议的情况下给出结论。
  • 禁止假设部署或网络拓扑（除非明确说明）；仅聚焦范围内的代码与配置。

Self-Check

自我检查

  • Was only the security dimension reviewed (no scope/language/architecture)?
  • Are injection, sensitive data, authz, dependencies, config/secrets, and crypto covered where relevant?
  • Is each finding emitted with Location, Category=cognitive-security, Severity, Title, Description, and optional Suggestion?
  • Are critical issues clearly marked and actionable?
  • 是否仅审查了安全维度（未涉及范围/语言/架构）？
  • 是否覆盖了注入、敏感数据、授权、依赖项、配置/密钥、加密相关的相关内容？
  • 每个问题发现是否包含位置、类别=cognitive-security、严重程度、标题、描述及可选的建议？
  • 严重问题是否已明确标记且具备可操作性？

Examples

示例

Example 1: Hardcoded secret

示例1：硬编码密钥

  • Input: API key or password in source code.
  • Expected: Emit a critical finding; suggest environment variable or secret manager; reference the line. Category = cognitive-security.
  • 输入：源代码中包含API密钥或密码。
  • 预期输出：输出一个严重（critical）级别的问题发现；建议使用环境变量或密钥管理工具；引用对应的行号。类别 = cognitive-security。

Example 2: SQL built from user input

示例2：由用户输入拼接的SQL语句

  • Input: Query string built with concatenation of user-controlled input.
  • Expected: Emit a critical finding for SQL injection; suggest parameterized queries. Category = cognitive-security.
  • 输入：通过拼接用户可控输入构建查询字符串。
  • 预期输出：输出一个SQL注入的严重（critical）级别问题发现；建议使用参数化查询。类别 = cognitive-security。

Edge case: False positive

边缘案例：误报

  • Input: Placeholder like "changeme" or "TODO" in config, not used in production.
  • Expected: Emit a minor/suggestion finding to remove or replace before production; do not mark as critical if context indicates non-production. If unclear, ask user or emit as suggestion.
  • 输入：配置中的占位符如"changeme"或"TODO"，并非用于生产环境。
  • 预期输出：输出一个次要/建议级别的问题发现，建议在发布前移除或替换；若上下文表明为非生产环境，请勿标记为严重级别。若情况不明确，可询问用户或作为建议输出。

Appendix: Output contract

附录：输出规范

Each finding MUST follow the standard findings format:
ElementRequirement
Location
path/to/file.ext
(optional line or range).
Category
cognitive-security
.
Severity
critical
| 
major
| 
minor
| 
suggestion
.
TitleShort one-line summary.
Description1–3 sentences.
SuggestionConcrete fix or improvement (optional).
Example:
markdown
- **Location**: `config/app.yml:7`
- **Category**: cognitive-security
- **Severity**: critical
- **Title**: API key hardcoded in configuration
- **Description**: Secret is committed to repo and may be exposed in logs or backups.
- **Suggestion**: Move to environment variable or secret manager; add to .gitignore if local override.
每个问题发现必须遵循以下标准格式：
元素要求
Location
path/to/file.ext
（可选行号或范围）。
Category
cognitive-security
。
Severity
critical
| 
major
| 
minor
| 
suggestion
。
Title简短的一行摘要。
Description1–3句话。
Suggestion具体的修复或改进建议（可选）。
示例：
markdown
- **Location**: `config/app.yml:7`
- **Category**: cognitive-security
- **Severity**: critical
- **Title**: API key hardcoded in configuration
- **Description**: Secret is committed to repo and may be exposed in logs or backups.
- **Suggestion**: Move to environment variable or secret manager; add to .gitignore if local override.