技能（Skill）：审查安全性

目的 (Purpose)

仅检查安全问题的代码。不要定义范围（差异与代码库）或执行语言/框架/架构分析；这些是单独的原子技能。以标准格式发出结果列表以进行聚合。重点关注注入（SQL、命令、模板）、敏感数据和日志记录、身份验证和授权、依赖项和 CVE、配置和机密以及加密和哈希。

核心目标（Core Objective）

首要目标：生成一个以安全为中心的结果列表，涵盖给定代码范围的注入、敏感数据、身份验证/授权、依赖项、配置和加密。

成功标准（必须满足所有要求）：

✅ 仅安全范围：仅审查安全维度；未执行范围选择、语言/框架约定或架构分析
✅ 涵盖所有六个类别：在相关的情况下评估注入、敏感数据/日志记录、身份验证/授权、依赖项/CVE、配置/秘密和加密技术
✅ 符合调查结果格式：每个调查结果包括位置、类别（“cognitive安全”）、严重性、标题、描述和可选建议
✅ 标记严重问题：明确的漏洞（例如硬编码秘密、SQL 注入）被标记为“严重”严重性
✅ 可操作的输出：每个发现都有特定的位置参考和具体的修复或改进建议

验收测试：输出是否包含标准格式的调查结果列表，涵盖所有相关的安全维度，并明确标记关键漏洞并提供可操作的建议？

范围边界（范围边界）

本技能负责：

注入漏洞（SQL、命令、模板、路径遍历）
日志、响应或客户端存储中的敏感数据暴露
身份验证和授权弱点（身份验证绕过、IDOR、CSRF、会话处理）
依赖漏洞和CVE评估
配置和秘密管理问题
密码学弱点和密钥管理问题

本技能不负责：

范围选择（决定要分析哪些文件/路径）——范围由调用者提供
语言/框架约定分析——使用“review-dotnet”、“review-java”、“review-go”等。
架构分析——使用“review-architecture”
绩效分析——使用“review-performance”
SQL特定的深度审查（使用“review-sql”进行全面的SQL分析）
全面精心策划的审核——使用“审核代码”

转交点：发出所有安全发现后，将其移交给“审查代码”编排器以与其他cognitive发现进行聚合，或直接交付给用户进行以安全为重点的审查会话。

使用场景（用例）

精心安排的审查：当review-code运行范围→语言→框架→库→cognitive时用作cognitive步骤。
以安全为中心的审查：当用户只想检查安全维度时（例如在发布或审核之前）。
合规性或审核：作为文档化的可重复安全检查表输出。

何时使用：当任务包含安全审核时。范围和代码范围由调用者或用户确定。

行为（行为）

该技能的范围

分析：给定代码范围中的安全维度（调用者提供的文件或差异）。不决定范围；接受代码范围作为输入。
不要：执行范围选择、语言/框架约定或架构审查。只关注安全。

审查清单（仅限安全维度）

注入：SQL注入（参数化、原始查询）；命令注入（shell、exec）；模板注入（用户控制的模板）；路径遍历；相关的 LDAP/XML 注入。
敏感数据和日志记录：日志或错误消息中的秘密、令牌或 PII； URL 或客户端存储中的敏感数据；响应或缓存中的暴露。
身份验证和授权：身份验证缺失或较弱；访问控制损坏（IDOR，权限升级）；会话处理和 CSRF；对每个敏感操作进行权限检查。
依赖项和 CVE：已知的易受攻击的依赖项（版本、建议）；未固定或版本范围过于宽泛；供应链和完整性。
配置和秘密：硬编码的秘密；配置文件或环境中的秘密；安全的默认配置；生产中的功能标志和调试模式。
加密和散列：较弱或已弃用的算法（例如用于安全的 MD5、SHA1）；加密使用不当；密钥管理和存储；密码散列（例如 bcrypt、Argon2）。

语气和参考

专业和技术：参考具体位置（文件：行）。发出包含位置、类别、严重性、标题、描述、建议的结果。对于明显的漏洞使用严重程度。

输入与输出 (Input & Output)

输入（输入）

代码范围：用户或范围技能已选择的文件或目录（或差异）。该技能不决定范围；它仅出于安全目的审查所提供的代码。

输出（输出）

以附录：输出合同中定义的格式发出零个或多个结果。
此技能的类别是cognitive安全。

限制（限制）

硬边界（Hard Boundaries）

不要执行范围选择、语言、框架或架构审查。保持在安全范围内。
不要在没有具体地点或可行建议的情况下给出结论。
不要假设部署或网络拓扑，除非另有说明；重点关注范围内的代码和配置。

技能边界 (Skill Boundaries)

不要做这些（其他技能可以处理它们）：

不要选择或定义代码范围（差异与代码库）——范围由调用者或“审查代码”确定
不要执行语言/框架约定分析 - 使用 review-dotnet、review-java、review-go 等。
不要执行架构或性能审查——使用“review-architecture”或“review-performance”
不要执行全面的 SQL 分析 — 使用 review-sql

何时停止并交接：

当所有安全结果发布后，将其移交给“审查代码”以在精心策划的审查中进行聚合
当用户需要全面审查（范围+语言+cognitive）时，重定向到“审查代码”
当特定于 SQL 的安全问题占主导地位时，建议还运行“review-sql”以获得更深入的 SQL 覆盖

自检（Self-Check）

核心成功标准

仅安全范围：仅审查安全维度；未执行范围选择、语言/框架约定或架构分析
涵盖所有六个类别：在相关的情况下评估注入、敏感数据/日志记录、身份验证/授权、依赖项/CVE、配置/秘密和加密技术
符合调查结果格式：每个调查结果包括位置、类别（“cognitive安全”）、严重性、标题、描述和可选建议
已标记关键问题：明显的漏洞（例如硬编码机密、SQL 注入）被标记为“严重”严重性
可行的输出：每个发现都有特定的位置参考和具体的修复或改进建议

流程质量检查

是否仅审查了安全维度（没有范围/语言/架构）？
是否涵盖相关的注入、敏感数据、授权、依赖项、配置/秘密和加密？
每个发现是否都包含位置、类别=cognitive安全、严重性、标题、描述和可选建议？
关键问题是否明确标记且可采取行动？

验收测试

输出是否包含标准格式的调查结果列表，涵盖所有相关的安全维度，并明确标记关键漏洞并提供可操作的建议？

示例（示例）

示例 1：硬编码秘密

输入：源代码中的 API 密钥或密码。
预期：发出关键发现；建议环境变量或秘密管理器；参考该线。类别=cognitive安全。

示例 2：根据用户输入构建 SQL

输入：通过用户控制的输入串联构建的查询字符串。
预期：发出 SQL 注入的关键发现；建议参数化查询。类别=cognitive安全。

边缘情况：误报

输入：配置中的占位符，如“changeme”或“TODO”，不在生产中使用。
预期：发出在生产前删除或更换的次要/建议发现；如果上下文表明非生产，则不要标记为关键。如果不清楚，请询问用户或作为建议发出。

附录：输出合约

每项调查结果必须遵循标准调查结果格式：

元素	要求
位置	`path/to/file.ext`（可选行或范围）。
类别	“cognitive安全”。
严重性	`关键` \| `主要` \| `次要` \| `建议`。
标题	简短的一行摘要。
描述	1-3 句话。
建议	具体修复或改进（可选）。

示例：

- **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.

review-security