code-security-audit

name	code-security-audit
description	对代码项目进行全面安全审计，支持 Python、Node.js、Go、Java 四种语言。 包含依赖漏洞扫描（结合原生工具 + Claude 分析）、代码安全模式检查（OWASP Top 10、注入、反序列化、 敏感信息泄露、认证授权、加密问题等）、业务逻辑审计、攻击链构建、配置审计、以及结构化报告输出。 触发场景：(1) 用户要求对项目进行安全审计/安全检查/代码审计 (2) 用户要求检查代码中的安全漏洞 (3) 用户要求进行依赖漏洞扫描 (4) 用户提到 security audit、vulnerability scan、代码审计、安全扫描、渗透测试前的代码审查 (5) 用户要求检查 OWASP Top 10 相关问题

代码安全审计

对项目执行安全审计，支持三种审计模式以平衡深度与 token 消耗。

审计模式选择

触发时先确定审计模式。用户明确指定则使用指定模式，否则默认 中度。

触发关键词	模式
"快速扫描"、"quick scan"、"轻度审计"、"light"	轻度
"安全审计"、"代码审计"、"audit"（默认）	中度
"深度审计"、"full audit"、"deep"、"渗透测试级"	深度

轻度审计（Quick Scan）

目标：快速发现高危问题，最小 token 消耗。

阶段	执行内容
Phase 1	仅识别语言/框架，不画模块地图和攻击面清单
Phase 2	单 Agent，仅搜索 Critical/High 级别模式（每语言 Top 10 高危模式）
Phase 3	跳过
Phase 4	跳过攻击链，仅基本验证（排除明显误报）
Phase 5	终端简要输出，不生成报告文件

不执行多轮审计。不加载 references 文件（使用内置知识）。依赖审计仅运行工具扫描，不做 Claude 分析。

轻度模式 Top 10 高危模式（跨语言通用）：

1. eval(/exec(/Runtime.exec/os.system — 代码/命令执行
2. pickle.loads/ObjectInputStream/yaml.load — 不安全反序列化
3. SQL 字符串拼接（"SELECT.*" + /Statement/${} in Mybatis）
4. 硬编码密码/密钥（password\s*=\s*["']/secret/api_key）
5. shell=True/child_process.exec — 命令注入
6. dangerouslySetInnerHTML/innerHTML/v-html — XSS
7. verify=False/InsecureSkipVerify — TLS 绕过
8. DEBUG\s*=\s*True/NODE_ENV.*development — 生产环境调试模式
9. cors.*origin.*\* — CORS 全开
10. log4j/fastjson 已知高危版本

中度审计（Standard Audit）

目标：覆盖主要安全风险，合理 token 消耗。

阶段	执行内容
Phase 1	完整信息收集 + 依赖审计（工具 + Claude 分析）
Phase 2	2-3 个 Agent 并行扫描，覆盖所有 Critical/High/Medium 模式
Phase 3	仅审计 P0 文件（认证链 + 未认证端点 + 核心 Sink 聚合点）
Phase 4	基本验证（四步法），不构建攻击链
Phase 5	完整报告（无攻击链章节）

单轮审计。按需加载 vulnerability_rules.md 中对应语言章节。

深度审计（Full Audit）

目标：最大化发现率，适合安全评审和渗透测试前审查。

执行完整五阶段流程 + 多轮审计策略 + 攻击链构建。即下文描述的全部内容。

---

审计哲学

核心分析模型

所有安全漏洞的本质：不可信的数据到达了危险的操作。

Source（源）      用户可控的输入入口
     ↓
Propagation（传播） 数据流经的函数、过滤、转换
     ↓
Sink（汇）        SQL执行、命令执行、文件读写等危险操作

审计的三个核心动作：

1. 找到所有 Source（识别攻击面）
2. 追踪 Propagation（验证中间是否有有效过滤）
3. 确认是否有未过滤的路径到达 Sink（漏洞判定）

优先级排序

优先级 = (攻击面大小 × 潜在影响) / 利用复杂度

维度	高权重	低权重
攻击面	未认证可达	内部接口
潜在影响	RCE、全库读取	信息收集
利用复杂度	单请求触发	需物理接触

第一条决策原则：永远优先审计认证链。 认证绕过能把所有需认证才能触发的漏洞升级为未认证漏洞。

五阶段审计流程

Phase 1: 信息收集与攻击面识别（10% 精力）

此阶段不搜漏洞，只产出四样东西：

1. 技术栈画像

• 检测语言标识文件：Python (requirements.txt等), Node.js (package.json等), Go (go.mod), Java (pom.xml等)
• 识别框架（Django/Flask/FastAPI, Express/Koa/Next.js, Gin/Echo, Spring/Mybatis）
• 识别数据库、中间件、模板引擎

2. 模块地图

• 扫描目录结构，识别路由层、控制器层、服务层、数据访问层
• 标注各模块的职责和依赖关系

3. 攻击面清单

• 列出所有 API 端点（HTTP 方法、路径、认证状态）
• 标记未认证端点、GET 写操作、管理端点（admin/metrics/swagger/actuator）
• 识别所有外部入口（API、WebSocket、消息队列、定时任务）和出口（HTTP 出站、邮件、文件写入）

4. 安全机制

• 识别认证方案（JWT/Session/OAuth）、授权中间件、CSRF 保护
• 识别输入校验方式、输出编码、加密方案

依赖审计也在此阶段执行：

• 运行 scripts/dep_audit.sh 或 scripts/dep_audit_java.sh（工具不可用则跳过）
• 读取依赖清单，分析已知高危版本、废弃包、typosquatting、宽泛版本范围

后续所有 Agent 的方向、搜索模式、优先级排序，全部基于这张地图推导。没有地图就没有方向。

Phase 2: 并行模式匹配扫描（30% 精力）

Agent 决策链：

Phase 1 攻击面清单 → 推导审计方向 → 按"可并行 + 不重叠"切分 Agent → 执行

核心原则：Agent 的方向由攻击面决定，不是固定模板。 项目没有文件上传就不设文件操作 Agent。

切分约束：

• 约束 1：搜索模式互不重叠，每个 Agent 有独占的 Grep 模式集
• 约束 2：可完全并行执行，Agent 之间零依赖

典型 Agent 映射（根据 Phase 1 发现动态调整）：

探测发现	审计方向	Agent 任务
Web 框架 + REST API	认证/授权链	Agent: 认证与授权
数据库连接	SQL/NoSQL 注入	Agent: 注入
文件上传 + HTTP 出站	SSRF + 文件操作	Agent: 文件/SSRF
模板引擎/eval/exec	XSS/SSTI/RCE	Agent: 代码执行
业务交易逻辑	IDOR/数值/竞态	Agent: 业务逻辑

Agent 数量：小型项目 2-3 个，中型 3-5 个，大型 5-9 个。

按语言加载对应规则，参考 references/vulnerability_rules.md。

核心检查项：

• 注入: SQL注入、命令注入、LDAP注入、模板注入(SSTI)、XSS
• NoSQL注入: MongoDB $where 拼接、操作符注入($gt/$ne/$regex)
• 反序列化: pickle/yaml/ObjectInputStream/Fastjson 不安全反序列化
• 认证授权: 硬编码凭证、JWT 配置、Session 管理、越权风险
• 加密: 弱算法(MD5/SHA1/DES)、硬编码密钥、不安全随机数
• 敏感信息: API Key/密码/Token 硬编码、日志泄露、错误信息泄露
• 文件操作: 路径遍历、不受限的文件上传
• SSRF/XXE: 不受限的 URL 请求、XML 外部实体
• 前端安全: innerHTML/dangerouslySetInnerHTML/bypassSecurityTrust*、前端路由泄露、前端硬编码凭据
• 业务逻辑: IDOR、Mass Assignment、数值校验缺失、竞态条件、CSRF、反自动化
• 原型污染 (Node.js) / Log4Shell (Java)
• 供应链: typosquatting、废弃包、可疑依赖来源

Phase 2 的核心产出是"高风险区域地图"，不是最终漏洞清单。发现率 30-50% 是正常的。

Phase 3: 关键路径深度审计（40% 精力）

对 Phase 2 标记的高风险文件做逐行审计。文件优先级排序：

优先级	文件类型	决策依据
P0	认证过滤器 / Token 处理	认证绕过影响全系统
P0	未认证可达的接口	直接暴露的攻击面
P0	Sink 最密集的核心业务入口	漏洞密度最高
P1	文件上传下载 / HTTP 出站工具类	路径遍历、SSRF
P2	配置类、加密工具类	配置缺陷、密钥管理

逐行审计逻辑：

对每个 P0/P1 文件:
  1. 读取完整结构（字段、方法列表）
  2. 从 public 方法开始，追踪每个参数的数据流
  3. 对每个分支判断:
     ├── 参数是否经过验证/过滤？→ 检查验证逻辑完整性
     ├── 参数是否到达 Sink？    → 记录完整路径
     └── 是否有绕过过滤的路径？ → 分析边界条件
  4. 记录: 文件 → 行号 → 漏洞类型 → 完整数据流路径

关键决策：优先审计 Sink 聚合点。 如果项目有统一的 HTTP 出站工具类，审计这一个文件就覆盖所有 SSRF 风险。

配置审计也在此阶段执行：

• DEBUG/开发模式、CORS 配置、安全 HTTP 头、数据库明文密码
• TLS/SSL 配置、Docker/K8s 安全（特权容器、root 运行）
• .env 文件是否被 .gitignore 排除
• Swagger/Actuator 等管理端点暴露

Phase 4: 漏洞验证与攻击链构建（15% 精力）

验证四步法 — 每个疑似漏洞必须过四关：

步骤	验证项	判定标准
1	数据流完整性	Source 到 Sink 中间无截断过滤
2	防护可绕过性	安全检查是否有遗漏的边界条件
3	前置条件可满足性	攻击者能否到达漏洞触发点
4	影响范围	利用后最大损害（RCE？数据泄露？提权？）

四步全过 → 确认漏洞。任一步不过 → 降级或排除。

攻击链构建：

对每个 Critical/High 漏洞:
  1. 确认前置条件（需要认证？什么权限？什么网络位置？）
  2. 如果需要认证 → 检查是否有认证绕过可串联
  3. 确认利用结果（信息泄露？代码执行？权限提升？）
  4. 检查结果能否作为下一个漏洞的输入
  5. 组合为完整攻击链，评估整体影响

典型攻击链模式参考 references/vulnerability_rules.md 中的攻击链模式章节。

等级影响规则：漏洞 A（认证绕过）消除漏洞 B 的认证前置条件 → B 按"未认证可达"重新评估。编号等级 = 独立等级，攻击链部分 = 组合等级。

Phase 5: 报告输出（5% 精力）

参考 references/report_template.md 输出。

报告包含：

1. 审计摘要（各严重程度的发现数量）
2. 攻击面地图（端点清单、认证状态）
3. 漏洞详情（位置、代码片段、完整数据流路径、修复建议、CWE 编号）
4. 攻击链分析（漏洞组合路径、整体影响）
5. 依赖审计结果
6. 配置审计结果
7. 修复优先级建议

多轮审计策略

单轮审计漏报率可达 50-60%。多轮审计每轮执行不同类型的分析：

轮次	目标函数	方法	发现类型
第一轮	max(覆盖面)	模式匹配（Grep + 并行 Agent）	表面可见：硬编码、未验证、配置缺陷
第二轮	max(深度)	数据流追踪（逐行 Read）	隐藏在数据流中：拼接链、协议注入、权限缺失
第三轮	max(关联度)	跨模块交叉验证	组合才危险：IDOR+白名单、加密体系缺陷

轮次终止规则

每轮结束后，强制回答三个问题：

1. 有没有计划搜索但没搜到的区域？ YES → 需要下一轮（补盲区）
2. 发现的入口点是否都追踪到了 Sink？ NO → 需要下一轮（追数据流）
3. 高风险发现之间是否可能存在跨模块关联？ YES → 需要下一轮（交叉验证）

三个问题的答案全部为 NO → 终止。任一为 YES → 继续。

轮次规模参考

项目规模	典型轮次	Agent 总数
小型（<10K LOC）	1 轮	2-3 个
中型（10K-50K）	1-2 轮	3-5 个
大型（50K-200K）	2-3 轮	5-9 个
超大型（>200K）	2-4 轮	8-15 个

严重等级判定

三维决策模型：严重等级 = f(可达性, 影响范围, 利用复杂度)

                漏洞发现
                   │
           未认证可达？
             ╱        ╲
           YES         NO
           ╱             ╲
   RCE/全库读取？    RCE/全库读取？
     ╱     ╲         ╱     ╲
   YES     NO      YES     NO
    │       │       │       │
 Critical   │     High   Medium/Low
         广范围数据
         泄露/篡改？
          ╱    ╲
        YES    NO
         │      │
       High   Medium

编号体系：C-001 (Critical 9.0-10.0), H-001 (High 7.0-8.9), M-001 (Medium 4.0-6.9), L-001 (Low 0.1-3.9)

排序策略：影响最广排最前 → 攻击链根漏洞优先 → 同模块漏洞相邻。

攻击链对等级的影响：

• 编号等级 = 独立等级（假设攻击者无其他漏洞）
• 攻击链部分 = 组合等级
• 修复链中一环不影响剩余漏洞的独立评级

误报处理

确认漏洞前必须验证：

• 危险函数的输入是否来自用户可控数据
• 是否存在上游的输入校验/转义/参数化
• 是否在测试代码中（测试代码中的 eval 通常不是漏洞）
• 框架是否已内置防护（如 Django ORM 默认参数化）

标记为 "可能的误报" 而非直接忽略，让用户自行判断。

快速参考

依赖审计脚本：

• 通用: scripts/dep_audit.sh <项目目录> [python|node|go|auto]
• Java: scripts/dep_audit_java.sh <项目目录>

漏洞规则详情: references/vulnerability_rules.md 报告模板: references/report_template.md