---
name: vulnerability-analysis
description: 当需要进行安全漏洞分析、安全评估或安全审计时使用此规则——安全漏洞分析方法和技术指导。包括：分析代码中的安全漏洞；识别潜在的安全风险；评估漏洞的严重程度和影响；使用安全分析工具和方法；审查代码的安全性；提供漏洞修复建议；生成安全评估报告；进行安全审计和检查；跟踪已知漏洞和CVE；验证漏洞修复的有效性。每当用户提及"漏洞分析"、"安全评估"、"安全审计"、"漏洞扫描"、"安全检查"、"安全风险"、"CVE"或需要漏洞分析、安全评估、安全审计时触发，无论涉及的代码或系统类型如何。如果需要进行安全漏洞分析、安全评估或安全审计，请使用此规则。
---

# 安全漏洞分析规则

## 你必须遵循的工作流程

### 1. 代码理解与分析阶段

- **必须**：使用 `read_code` 工具阅读和理解用户提供的代码文件或目录
- **必须**：分析代码的整体架构、模块划分和数据流
- **必须**：如有不明确的代码功能，需通过其他方式获取信息
- **禁止**：在不了解代码功能的情况下直接进行漏洞扫描

### 2. 漏洞扫描与识别阶段

- **必须**：结合静态代码分析和专业知识，查找潜在的安全漏洞
- **必须**：关注用户输入处理、数据验证、认证授权、会话管理等关键部分
- **必须**：检查是否存在不安全的API使用或配置错误
- **必须**：使用 `search_web` 工具查询已知的库漏洞或CVE信息
- **禁止**：遗漏常见的安全漏洞类型（SQL注入、XSS、CSRF、命令注入等）

### 3. 逻辑缺陷挖掘阶段

- **必须**：分析代码的业务逻辑，寻找可能被滥用的功能点
- **必须**：检查代码在处理并发、事务、状态转换等方面的正确性
- **必须**：关注代码的错误处理和异常捕获机制
- **禁止**：仅关注技术漏洞而忽视业务逻辑缺陷

### 4. 报告生成阶段

- **必须**：整理发现的所有问题，并编写详细的分析报告
- **必须**：对每个问题，提供清晰的描述、严重程度评级、复现步骤和修复建议
- **必须**：在报告中包含问题位置（文件和行号）、触发场景和潜在影响
- **必须**：按照标准格式输出漏洞分析报告

## 你必须遵守的原则

### 专业性原则

- **必须**：保持专业、严谨的技术分析风格
- **必须**：对漏洞的判断提供充分的依据和证据
- **必须**：在遇到不确定的情况时，向用户寻求确认，而不是做出假设
- **禁止**：提供没有根据的漏洞猜测或推测

### 全面性原则

- **必须**：深入理解代码功能和业务逻辑
- **必须**：识别常见的安全漏洞类型（SQL注入、XSS、CSRF、命令注入等）
- **必须**：发现代码中的逻辑缺陷和边界条件问题
- **必须**：分析代码的依赖关系和第三方库的安全性
- **必须**：评估漏洞的严重程度和潜在影响

### 可操作性原则

- **必须**：提供具体、可操作的修复建议
- **必须**：对关键问题提供代码片段作为示例
- **必须**：按照清晰的报告格式组织分析结果
- **禁止**：提供模糊或不切实际的修复方案

## 具体要求和规范

### 漏洞分析报告要求

- **必须**：提供一份完整的漏洞分析报告
- **必须**：报告格式清晰，易于阅读和理解
- **必须**：包含问题的关键信息：问题位置、问题描述、严重程度、触发场景、影响范围
- **必须**：对每个漏洞进行严重程度评级（高危、中危、低危）
- **必须**：提供具体的复现步骤和验证方法
- **必须**：将报告输出为文件（推荐使用 Markdown 格式，文件命名建议为 `security_analysis_report.md` 或 `vulnerability_analysis_report.md`）
- **必须**：报告文件保存在项目根目录或指定的报告输出目录中

### 分析覆盖范围

- **必须**：覆盖用户输入处理和数据验证逻辑
- **必须**：检查认证授权机制的安全性
- **必须**：分析会话管理的安全性
- **必须**：评估第三方库和依赖的安全性
- **必须**：关注代码中的并发和事务处理逻辑

### 任务拆分要求

- **必须**：对于复杂的安全漏洞分析任务（涉及多个文件、多个模块或需要多步骤分析），必须使用 `task_list_manager` 工具将任务拆分为多个子任务
- **必须**：任务拆分应遵循合理粒度原则，每个子任务应该独立可执行、目标明确、可验证
- **必须**：在拆分任务时，明确任务之间的依赖关系，确保执行顺序正确
- **必须**：为每个子任务提供清晰的描述、预期输出和验证标准
- **禁止**：过度拆分简单任务，避免不必要的信息传递负担

## 实践指导

### 漏洞分析最佳实践

1. **系统性分析方法**
   - 从整体架构入手，逐步深入到具体实现细节
   - 按照漏洞类型分类进行检查，确保不遗漏
   - 结合自动化工具和人工分析，提高发现效率

2. **重点关注区域**
   - 所有用户输入点都是潜在的攻击入口
   - 权限检查和控制逻辑是安全的核心
   - 数据处理和数据存储环节容易出现注入漏洞
   - 错误处理不当可能泄露敏感信息

3. **漏洞验证技巧**
   - 对发现的潜在漏洞，尝试构造测试用例验证
   - 使用已知的安全测试模式和Payload进行验证
   - 关注边界条件和异常处理路径

### 报告编写建议

- 使用结构化的格式组织报告内容
- 按照严重程度优先级排列发现的问题
- 为每个问题提供清晰的修复代码示例
- 包含预防类似问题的开发建议

## 执行检查清单

在开始漏洞分析前，你必须确认：

- [ ] 已完整阅读和理解待分析的代码
- [ ] 已了解代码的业务逻辑和使用场景
- [ ] 已准备好漏洞分析所需的工具和环境

在漏洞分析过程中，你必须确认：

- [ ] 已检查所有用户输入处理逻辑
- [ ] 已验证认证授权机制的完整性
- [ ] 已分析会话管理的安全性
- [ ] 已评估第三方依赖的安全性
- [ ] 已关注业务逻辑缺陷和并发问题

在完成分析报告后，你必须确认：

- [ ] 报告包含所有发现的安全问题
- [ ] 每个问题都有明确的严重程度评级
- [ ] 提供了具体、可操作的修复建议
- [ ] 报告格式清晰，易于理解和执行
- [ ] 已验证报告中的技术准确性
