审计验证流水线

触发条件

触发场景

决策流程

发现可疑代码 → 写 PoC → forge build → forge test
  ├─ PASS + 攻击效果确认 → 质量自评 → 提交宝总决策 → (是) 提交外部平台
  ├─ PASS + 无攻击效果 → 丢弃（FALSE POSITIVE）
  └─ FAIL → 修复（最多3轮）→ 仍失败 → 丢弃

反触发（不使用此技能的场景）

• 没有 PoC 代码时：纯代码审查或白板分析不需要 forge 验证
• 非 Solidity 项目：此流水线基于 Foundry，不适用于 Rust/Go/Python 审计
• 理论级发现：没有可运行 PoC 的发现标记为理论级，不进入验收流程
• 宝总明确说"先看看"时：探索阶段不触发正式验收

概述

三级验收流水线，确保每个审计 finding 经过确定性验证后才作为交付物。

核心原则: 代码生成虽具概率性，但验证是确定性的。没有 forge test PASS 的 finding 不是交付物。

三级验收

Level 1: Self-Verification (forge test PASS)
Level 2: GitHub CI (automated, prevents skipping)
Level 3: Auditor Review (novelty, severity, quality)

串行依赖关系：L1 → L2 → L3。跳过任一环节 = 未验证。

Level 1: Self-Verification

分步操作

1. 阅读源码 → 识别可疑模式
2. 编写 finding 描述（初稿）
3. 编写 Foundry PoC (.t.sol)
4. forge build → 修复编译错误（预期需 2–3 轮迭代）
5. forge test → 检查结果：
   - PASS + 攻击效果确认 → REAL
   - PASS + 攻击效果 = 0 → FALSE POSITIVE
   - FAIL（PoC 缺陷）→ 修复 PoC，重试
   - FAIL（被测代码正确）→ FALSE POSITIVE，丢弃
6. 质量自评
7. 向 宝总 汇报，申请进入 Level 3 决策

PoC 模板

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.x;

import "forge-std/Test.sol";
import "../src/TargetContract.sol";

contract POC_FindingName is Test {
    TargetContract target;

    function setUp() public {
        // 部署合约
        // 初始化状态
    }

    function test_attack_succeeds() public {
        // 步骤 1：准备攻击前提条件
        // 步骤 2：执行攻击
        // 步骤 3：断言攻击效果（NOT 仅断言交易成功）
        assertGt(attackerProfit, 0, "Attack must produce profit");
    }
}

常见陷阱

1. vm.roll vs vm.warp: vm.roll 仅修改区块号，需改时间戳请用 vm.warp
2. StaleMessage: 部分协议校验消息新鲜度，需设置正确时间戳
3. NotTolled/Payable: 认证类函数可能要求支付费用（例如 kiss()）
4. Solidity 中的 Unicode 字符: 替换 —、→ 等非 ASCII 符号为纯 ASCII
5. 库路径: 核对实际文件位置，勿依赖假设路径
6. 虚拟份额/余额: 协议特定的虚拟记账机制可能吸收舍入误差（参考 Morpho 教训）
7. PASS ≠ 正确: PoC 通过不代表 finding 成立——须验证攻击 EFFECT，而非仅机制可行

质量自评模板

【提交前质量自评】
- Finding ID: [F-XX]
- 验证状态: [ ] 已编译 [ ] forge test PASS [ ] 攻击效果已确认
- 严重度: [H/M/L/I] — 理由: [为何定为此严重度]
- 新颖性: [New / Known / Duplicate] — 若已知，请注明来源: [link]
- 已知限制: [任何注意事项或边界条件]

Level 2: GitHub CI（待补充）

必需工作流

# .github/workflows/audit-test.yml
name: Audit PoC Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: foundry-rs/foundry-toolchain@v1
      - run: forge test --match-path "test/POC_*.t.sol" -vv
      - run: forge build

目的

防止因会话中断或记忆疏漏而跳过 Level 1。每次推送均须通过 forge test，方可提交 PR。

Level 3: 审计师复核

审计师核查内容（forge test 无法覆盖）

1. 新颖性: 该 finding 是否已被发现？需查阅历史审计报告
2. 严重度准确性: Medium 是否确为 Medium？（Sablier 教训：2/5 存在高估）
3. 影响量化: 精确计算损失金额，而非定性描述
4. 报告质量: 清晰的复现步骤、代码引用、修复建议
5. 协议经济学: DeFi 场景下的博弈论分析与激励机制评估

提交前检查清单

• forge test PASS（Level 1）
• 推送后 CI 通过（Level 2）
• 已比对历史审计报告，排除重复项
• 严重度判定附有数据支撑
• 影响已量化（不可仅写“资金损失”）
• 报告符合目标平台提交格式
• 已向 宝总 汇报并获准提交

严重度评估指南

常见高估情形：若影响发生需同时满足多个低概率条件，应下调一级。 常见低估情形：若影响具有系统性（波及全部用户），应上调一级。

回溯验证复盘经验（2026-03-31）

• 共提交 135 个 finding，0 个经验证 → Cantina 封禁
• 29 个 finding 进行回溯验证：28 个真实（96.6%），1 个误报（3.4%）
• 代码分析能力扎实；验证层此前缺失
• 误报示例：Morpho F-01（虚拟份额吸收舍入误差）
• 严重度高估示例：Sablier F-03、F-05（Medium → Low）
• PoC 编译报错属正常现象，预期需 2–3 轮修复
• forge test PASS ≠ finding 成立，务必验证攻击 EFFECT，而非仅机制可行