技能（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.