nesnilnehc/review-security

技能（Skill）：审查安全性

目的 (Purpose)

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

---

核心目标（Core Objective）

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

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

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

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

---

范围边界（范围边界）

本技能负责：

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

本技能不负责：

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

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

---

使用场景（用例）

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

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

---

行为（行为）

该技能的范围

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

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

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

语气和参考

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

---

输入与输出 (Input & Output)

输入（输入）

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

输出（输出）

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

---

限制（限制）

硬边界（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-security”）、严重性、标题、描述和可选建议
• [ ] 已标记关键问题：明显的漏洞（例如硬编码机密、SQL 注入）被标记为“严重”严重性
• [ ] 可行的输出：每个发现都有特定的位置参考和具体的修复或改进建议

流程质量检查

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

验收测试

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

---

示例（示例）

示例 1：硬编码秘密

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

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

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

边缘情况：误报

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