security-review

安全审查

一个 AI 驱动的安全扫描器，像人类安全研究员一样对你的代码库进行推理——追踪数据流、理解组件交互，并捕捉模式匹配工具会漏掉的漏洞。

何时使用此技能

当请求涉及以下内容时，使用此技能：

• 扫描代码库或文件中的安全漏洞
• 运行安全审查或漏洞检查
• 检查 SQL 注入、XSS、命令注入或其他注入缺陷
• 查找代码中暴露的 API 密钥、硬编码密钥或凭证
• 审计依赖项中的已知 CVE
• 审查认证、授权或访问控制逻辑
• 检测不安全的加密或弱随机性
• 执行数据流分析，以追踪用户输入到危险汇点
• 任何类似“我的代码安全吗？”、“扫描这个文件”或“检查我的仓库是否有漏洞”的请求措辞
• 运行 /security-review 或 /security-review <path>

此技能如何工作

与匹配模式的传统静态分析工具不同，此技能：

1. 像安全研究员一样阅读代码——理解上下文、意图和数据流
2. 跨文件追踪——跟踪用户输入如何在你的应用中移动
3. 自我验证发现——重新检查每个结果以过滤误报
4. 分配严重性评级——CRITICAL / HIGH / MEDIUM / LOW / INFO
5. 提出针对性补丁——每个发现都包含具体修复
6. 需要人工批准——不会自动应用任何内容；你始终先审查

执行工作流

每次按顺序遵循以下步骤：

步骤 1 — 范围解析

确定要扫描的内容：

• 如果提供了路径（/security-review src/auth/），仅扫描该范围
• 如果未提供路径，则从根目录开始扫描整个项目
• 识别所使用的语言和框架（检查 package.json、requirements.txt、 go.mod、Cargo.toml、pom.xml、Gemfile、composer.json 等）
• 阅读 references/language-patterns.md 以加载特定语言的漏洞模式

步骤 2 — 依赖项审计

在扫描源代码之前，先审计依赖项（快速收益）：

• Node.js：检查 package.json + package-lock.json 中是否存在已知易受攻击的包
• Python：检查 requirements.txt / pyproject.toml / Pipfile
• Java：检查 pom.xml / build.gradle
• Ruby：检查 Gemfile.lock
• Rust：检查 Cargo.toml
• Go：检查 go.sum
• 标记具有已知 CVE、已弃用加密库或可疑地过旧的固定版本的包
• 阅读 references/vulnerable-packages.md 以获取精选的关注列表

步骤 3 — 密钥与暴露扫描

扫描所有文件（包括配置、env、CI/CD、Dockerfiles、IaC），查找：

• 硬编码的 API 密钥、令牌、密码、私钥
• 意外提交的 .env 文件
• 注释或调试日志中的密钥
• 云凭证（AWS、GCP、Azure、Stripe、Twilio 等）
• 嵌入了凭证的数据库连接字符串
• 阅读 references/secret-patterns.md 以获取要应用的正则表达式模式和熵启发式方法

步骤 4 — 漏洞深度扫描

这是核心扫描环节。要对代码进行推理分析 —— 不要只做模式匹配。 阅读 references/vuln-categories.md 了解每个类别的完整细节。

注入缺陷

• SQL 注入：使用字符串插值的原始查询、ORM 误用、二次 SQLi
• XSS：未转义的输出、dangerouslySetInnerHTML、innerHTML、模板注入
• 命令注入：将用户输入传入 exec/spawn/system
• LDAP、XPath、Header、日志注入

身份验证与访问控制

• 敏感端点缺少身份验证
• 对象级授权失效（BOLA/IDOR）
• JWT 弱点（alg:none、弱密钥、无过期校验）
• 会话固定、缺少 CSRF 防护
• 权限提升路径
• 批量赋值 / 参数污染

数据处理

• 日志、错误消息或 API 响应中的敏感数据
• 缺少静态或传输中加密
• 不安全的反序列化
• 路径遍历 / 目录遍历
• XXE（XML 外部实体）处理
• SSRF（服务器端请求伪造）

密码学

• 将 MD5、SHA1、DES 用于安全目的
• 硬编码 IV 或盐值
• 弱随机数生成（用 Math.random() 生成令牌）
• 缺少 TLS 证书校验

业务逻辑

• 竞态条件（TOCTOU）
• 财务计算中的整数溢出
• 敏感端点缺少限流
• 可预测的资源标识符

步骤 5 — 跨文件数据流分析

完成逐文件扫描后，执行一次整体审查：

• 追踪用户可控输入从入口点（HTTP 参数、请求头、请求体、文件上传） 一直到汇聚点（数据库查询、exec 调用、HTML 输出、文件写入）的完整路径
• 识别只有在同时查看多个文件时才会出现的漏洞
• 检查服务或模块之间是否存在不安全的信任边界

步骤 6 — 自我验证环节

对每一项发现：

1. 以全新的视角重新阅读相关代码
2. 问自己：“这真的可被利用吗，还是我漏掉了某处净化处理？”
3. 检查是否已有框架或中间件在上游处理了该问题
4. 对并非真实漏洞的发现进行降级或丢弃
5. 分配最终严重级别：CRITICAL / HIGH / MEDIUM / LOW / INFO

步骤 7 — 生成安全报告

按照 references/report-format.md 中定义的格式输出完整报告。

步骤 8 — 提出补丁

对每一项 CRITICAL 和 HIGH 发现，生成一个具体补丁：

• 展示有漏洞的代码（修改前）
• 展示修复后的代码（修改后）
• 说明改了什么以及为什么
• 保留原有代码风格、变量名和结构
• 内联添加一条说明修复的注释

明确声明：“应用每个补丁前请先审查。目前尚未做任何更改。”

严重级别指南

严重级别	含义	示例
🔴 CRITICAL	可立即被利用的风险，很可能导致数据泄露	SQLi、RCE、身份验证绕过
🟠 HIGH	严重漏洞，存在利用路径	XSS、IDOR、硬编码密钥
🟡 MEDIUM	在特定条件或链式组合下可被利用	CSRF、开放重定向、弱加密
🔵 LOW	最佳实践违规，直接风险低	详细错误信息、缺少响应头
⚪ INFO	值得注意的观察项，并非漏洞	过时的依赖（无 CVE）

输出规则

• 始终先产出一张发现汇总表（按严重级别计数）
• 绝不自动应用任何补丁 —— 仅将补丁提交供人工审查
• 始终为每项发现附上置信度评级（High / Medium / Low）
• 按类别分组呈现发现，而不是按文件
• 要具体 —— 包含文件路径、行号以及确切的漏洞代码片段
• 用通俗语言解释风险 —— 攻击者能借此做什么？
• 如果代码库是干净的，请清楚说明：“未发现漏洞”，并说明扫描了哪些内容

参考文件

如需详细的检测指导，可按需加载以下参考文件：

• references/vuln-categories.md — 每个漏洞类别的深度参考，包含检测信号、安全模式和升级检查器
  • 搜索模式：SQL injection、XSS、command injection、SSRF、BOLA、IDOR、JWT、CSRF、secrets、cryptography、race condition、path traversal
• references/secret-patterns.md — 正则表达式模式、基于熵的检测以及 CI/CD 密钥风险
  • 搜索模式：API key、token、private key、connection string、entropy、.env、GitHub Actions、Docker、Terraform
• references/language-patterns.md — 针对 JavaScript、Python、Java、PHP、Go、Ruby 和 Rust 的框架特定漏洞模式
  • 搜索模式：Express、React、Next.js、Django、Flask、FastAPI、Spring Boot、PHP、Go、Rails、Rust
• references/vulnerable-packages.md — 针对 npm、pip、Maven、Rubygems、Cargo 和 Go modules 的精选 CVE 观察列表
  • 搜索模式：lodash、axios、jsonwebtoken、Pillow、log4j、nokogiri、CVE
• references/report-format.md — 安全报告的结构化输出模板，包含发现卡片、依赖审计、密钥扫描和补丁建议格式
  • 搜索模式：report、format、template、finding、patch、summary、confidence