Security Audit

首次接触项目时，建立全局认知并生成初始审计 TODO 文档。

Step 0.1 — 技术栈识别

收集信息：
  - 编程语言与版本
  - 构建工具与配置文件 (Cargo.toml / package.json / go.mod / foundry.toml 等)
  - 依赖列表及版本
  - 项目类型判定：
    □ 密码学库        □ 智能合约       □ Web 后端服务
    □ CLI 工具        □ SDK/客户端库   □ 区块链节点
    □ 其他: _____

输出：一段项目概况摘要

Step 0.2 — 架构与入口分析

识别：
  - 公共 API 入口（导出的函数/类/接口/合约方法）
  - 内部模块划分
  - 数据流方向（输入从哪来、输出到哪去、中间经过什么处理）
  - 信任边界（哪些数据来自不可信来源）

输出：
  - 模块/组件列表
  - 关键数据流描述
  - 信任边界标注

Step 0.3 — 函数/方法关联分析

对每个公共 API 和关键内部函数，分析：
  - 调用关系（调用了谁、被谁调用）
  - 输入来源（用户参数 / 外部数据 / 内部状态）
  - 输出去向（返回值 / 修改状态 / 写入存储）
  - 涉及的安全操作（加密/认证/授权/IO/资金转移 等）

输出：调用关系图 + 各 API 的完整调用链

Step 0.4 — 现有测试评估

扫描测试文件：
  - 统计测试数量
  - 识别测试类型（单元测试/集成测试/模糊测试）
  - 判断覆盖盲区（哪些函数/分支没有测试）

输出：测试覆盖摘要 + 缺口列表

Step 0.5 — 生成初始 TODO 文档

根据 Step 0.1 的项目类型，从"审计维度库"（见第五节）中选取适用维度，
结合 Step 0.2~0.4 的分析结果，为每个维度生成具体的 TODO 项。

输出：完整的 SECURITY_AUDIT_TODO.md（格式见第四节）

三、Phase 1 — 逐项深度审计

选取规则

每次会话选取 1~3 个 TODO 项，选取优先级：
  1. P0 > P1 > P2 > P3
  2. 同级内：底层基础函数 > 上层业务函数
  3. 同级内：处理外部输入的函数 > 纯内部函数
  4. 同级内：资金/密钥相关 > 数据处理 > 辅助功能

审计方法

A. 正向逻辑审查

逐行阅读关联源码：
  - 每个条件分支是否正确？
  - 前置条件（函数要求调用者保证的）是否被所有调用者满足？
  - 后置条件（函数承诺的输出/状态）是否在所有路径上成立？
  - 错误处理是否完备？是否存在被忽略的 Result/Error？

B. 逆向攻击思维

假设攻击者完全控制所有外部输入，尝试构造：
  - 零值 / 空值 / null
  - 边界值（最小值、最大值、差一）
  - 超大值（触发溢出/OOM）
  - 畸形格式（无效编码、截断数据、多余数据）
  - 重复/重放（相同输入发送多次）
  - 语义冲突（合法格式但语义矛盾的数据）

检查是否导致：
  - 崩溃 / panic / 未捕获异常
  - 内存安全问题（越界/溢出/UAF）
  - 逻辑绕过（跳过验证/认证）
  - 信息泄露（通过错误消息/时间差/返回值差异）
  - 状态污染（全局/共享状态被破坏）
  - 资源耗尽（CPU/内存/磁盘/网络）

C. 上下文关联审查

不孤立看单个函数，要审查：
  - 该函数的所有调用者是否传入了合法参数？
  - 该函数的返回值是否被所有调用者正确处理？
  - 修改的共享状态是否被并发访问？
  - 是否存在 TOCTOU（检查与使用之间状态变化）？

输出格式

## AUDIT-{ID}: {标题}
### 状态: ✅ 通过 / ⚠️ 建议改进 / ❌ 发现漏洞
### 分析过程
  [逐步推理记录]
### 发现
  - [描述] — 严重级别 — 影响范围
### 关键代码引用
  [代码片段 + 位置]
### 修复建议
  [具体方案]
### 新增审计项（如有）
  [审计中发现的新攻击面，追加到 TODO 文档]

四、TODO 文档格式规范

# {项目名} 安全审计 TODO

> 版本: vN | 最后更新: YYYY-MM-DD | 状态: 进行中/已完成

## 项目概况
  - 语言: {language}
  - 类型: {project_type}
  - 依赖数: {N}
  - 源文件数: {N}
  - 现有测试数: {N}

## 审计进度
  - 总 TODO 项: {N}
  - ✅ 已完成: {N} | ❌ 发现问题: {N} | ⏳ 待审计: {N}

---

## 第 X 章: {审计维度名称}

- [ ] 🔴 **AUDIT-{DIM}-{NNN}**: {标题}
  - **关联代码**: {文件:函数名:行号}
  - **审计内容**:
    - {具体检查点 1}
    - {具体检查点 2}
  - **现有覆盖**: {已有测试是否覆盖}
  - **发现记录**: （审计完成后填写）

状态标记:
  [ ] 待审计  [~] 审计中  [x] 通过  [!] 发现问题

优先级:
  🔴 P0-Critical  🟠 P1-High  🟡 P2-Medium  🟢 P3-Low

---

## 附录 A: 审计执行日志
| 日期 | 审计项 | 发现摘要 | 状态 |
|------|--------|---------|------|

## 附录 B: 新增项跟踪
| 日期 | 新增项 ID | 来源 | 描述 |
|------|----------|------|------|

## 附录 C: 修复建议
| 审计项 | 严重级别 | 建议方案 | 修复状态 |
|--------|---------|---------|---------|

五、审计维度库

根据 Phase 0 识别的项目类型，选取适用的维度组合。 每个维度下列出了通用检查点，具体 TODO 项在 Phase 0.5 结合实际代码生成。

DIM-INPUT: 输入验证

适用: 所有项目
检查点:
  □ 所有外部入口的参数是否有类型/范围/格式校验
  □ 缺失参数/空值/null 的处理
  □ 超长/超大输入是否被拒绝或截断
  □ 编码/解码是否正确处理无效输入
  □ 反序列化是否安全（无 RCE/内存破坏风险）

DIM-CRYPTO: 密码学操作

适用: 涉及加密/签名/哈希/密钥管理的项目
检查点:
  □ 密钥派生是否使用充分的域分离
  □ 对称加密的 (key, nonce/IV) 是否唯一
  □ 认证标签/HMAC/签名 是否在解密/处理之前验证
  □ 比较操作是否使用恒定时间
  □ 随机数是否使用 CSPRNG 生成
  □ 敏感密钥材料使用后是否清零
  □ 哈希/MAC 输出是否完整使用（无不安全截断）
  □ 椭圆曲线点/标量 是否经过有效性验证

DIM-AUTH: 认证与授权

适用: 有用户/权限体系的项目
检查点:
  □ 认证可否被绕过（跳过校验的代码路径）
  □ 授权检查是否在每个敏感操作前执行
  □ 会话/Token 管理是否安全
  □ 权限提升是否可能
  □ 默认配置是否安全

DIM-LOGIC: 业务逻辑

适用: 所有项目
检查点:
  □ 状态机转换是否正确（无非法状态跳转）
  □ 竞态条件 / TOCTOU
  □ 重入/递归是否安全
  □ 数值计算精度与溢出
  □ 边界条件（空集合/单元素/满容量）
  □ 错误恢复后状态是否一致

DIM-MEMORY: 内存与资源安全

适用: 使用手动内存管理或不安全代码的项目 (C/C++/Rust unsafe/Solidity)
检查点:
  □ 数组/切片越界访问
  □ 整数溢出/下溢（算术运算 + 类型转换）
  □ 可触发 panic/abort/revert 的路径
  □ 内存泄漏
  □ 资源耗尽 (OOM/栈溢出/gas 耗尽)
  □ unsafe 代码块的安全不变量

CKB 合约排除项:
  ✗ 内存对齐 — CKB-VM 原生支持非对齐内存访问（unaligned memory access），
    因此在审计 CKB 合约时，无需检查内存对齐问题。指针强制转换访问
    非对齐地址（如 *(uint32_t*)(ptr + offset)）在 CKB-VM 上是安全的，
    不会触发对齐异常或未定义行为。

DIM-CONTRACT: 智能合约特定

适用: Solidity/Move/CosmWasm/CKB 等智能合约
检查点:
  □ 重入攻击
  □ 闪电贷/价格操纵
  □ 前置交易 (front-running)
  □ 访问控制 (owner/admin 权限)
  □ 代理合约升级安全
  □ 预言机依赖与操纵
  □ 精度损失与舍入方向
  □ 余额/总量一致性
  □ selfdestruct / delegatecall 滥用

CKB 合约排除项:
  ✗ 内存对齐 — CKB-VM 原生支持非对齐内存访问，无需审计内存对齐问题

DIM-DEPS: 依赖安全

适用: 所有项目
检查点:
  □ 依赖版本是否有已知 CVE
  □ 是否使用了已弃用/不维护的库
  □ 依赖的 feature flags 是否引入不需要的攻击面
  □ 供应链攻击风险（typosquatting/恶意包）
  □ 依赖许可证合规性

DIM-SERDE: 序列化/反序列化

适用: 涉及数据编解码/网络协议/文件格式的项目
检查点:
  □ 解析畸形/截断/超长数据的行为
  □ 序列化→反序列化 roundtrip 一致性
  □ 不可信来源的反序列化是否安全
  □ 版本/格式兼容性

DIM-ERRINFO: 错误处理与信息泄露

适用: 所有项目
检查点:
  □ 错误消息是否泄露内部状态/路径/密钥片段
  □ 不同错误原因是否可被外部区分（oracle 风险）
  □ 错误是否被静默忽略
  □ panic/异常 是否可由外部输入触发

DIM-SPEC: 规范一致性

适用: 实现了已知协议/标准的项目
检查点:
  □ 实现是否与参考规范逐条对应
  □ 可选/扩展部分的处理是否安全
  □ 与参考实现的差异是否有意为之

六、Phase 2 — TODO 文档更新规则

每次审计结束后必须：

1. 更新已审计项的状态和发现记录
2. 将审计中发现的新攻击面追加为新 TODO 项
3. 更新附录 A/B/C
4. 更新文档顶部的审计进度计数
5. 输出完整的更新后 TODO 文档

七、Phase 3 — 最终报告

触发条件

所有 P0/P1 项已完成，或用户主动要求生成报告。

报告结构

# 安全审计报告: {项目名}

## 1. 执行摘要
  项目信息、审计范围、关键数字

## 2. 风险评级
  ■ Critical: N 项 | ■ High: N 项 | ■ Medium: N 项 | ■ Low: N 项

## 3. 关键发现（按严重级别降序）
  每项含: ID/标题/描述/影响/复现/修复建议/代码引用

## 4. 审计覆盖矩阵
  函数/模块 × 审计维度 的覆盖状态表

## 5. 依赖安全状态

## 6. 改进建议（非漏洞类）

## 7. 附录: 完整 TODO 文档终态

八、AI 执行约束

1. 每次会话深度优于广度：宁可审完 1 项，不要浅过 5 项
2. 不确定的发现标记为"疑似"，不要臆断漏洞存在
3. 无法静态判断的问题（如需运行时验证），明确标注"需动态验证"
4. 对外部闭包/回调/用户自定义逻辑，分析最坏情况输入
5. 保持 TODO 文档为唯一的进度真相来源 (Single Source of Truth)
6. 每次输出都包含：本次做了什么 + 下次建议做什么