Audit Verification Pipeline
触发条件
触发场景
| 场景 | 对应能力 | 说明 |
|---|
| 写完 PoC 准备验证 | Level 1: Self-Verification | forge build + forge test 确认攻击效果 |
| 准备提交 finding 到外部平台 | Level 3: Pre-submission checklist | 提交前必须完成三级验收 |
| forge test 结果不确定 | Quality Self-Assessment | 判断 PASS 是否等于 finding 真实 |
| 判断 finding 严重度 | Severity Assessment Guide | 防止高估（Medium→Low 惯例） |
| 推送审计代码到 GitHub | Level 2: GitHub CI | CI 必须配置防止跳过验证 |
决策流程
发现可疑代码 → 写 PoC → forge build → forge test
├─ PASS + 攻击效果确认 → 质量自评 → 提交宝总决策 → (是) 提交外部平台
├─ PASS + 无攻击效果 → 丢弃（FALSE POSITIVE）
└─ FAIL → 修复（最多3轮）→ 仍失败 → 丢弃
反触发（不使用此技能的场景）
- 没有 PoC 代码时：纯代码审查或白板分析不需要 forge 验证
- 非 Solidity 项目：此流水线基于 Foundry，不适用于 Rust/Go/Python 审计
- 理论级发现：没有可运行 PoC 的发现标记为理论级，不进入验收流程
- 宝总明确说"先看看"时：探索阶段不触发正式验收
Overview
三级验收流水线，确保每个审计finding经过确定性验证后才作为交付物。
核心原则: 代码生成虽具概率性，但验证是确定性的。没有forge test PASS的finding不是交付物。
Three-Level Acceptance
Level 1: Self-Verification (forge test PASS)
Level 2: GitHub CI (automated, prevents skipping)
Level 3: Auditor Review (novelty, severity, quality)
Serial dependency: L1 → L2 → L3. Skipping levels = no verification.
Level 1: Self-Verification
Step-by-step
1. Read source code → identify suspicious pattern
2. Write finding description (draft)
3. Write Foundry PoC (.t.sol)
4. forge build → fix compilation errors (expect 2-3 rounds)
5. forge test → check result:
- PASS + attack effect confirmed → REAL
- PASS + attack effect = 0 → FALSE POSITIVE
- FAIL (PoC bug) → fix PoC, retry
- FAIL (code correct) → FALSE POSITIVE, discard
6. Quality self-assessment
7. Present to 宝总 for Level 3 decision
PoC Template
// 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 {
// Deploy contracts
// Setup state
}
function test_attack_succeeds() public {
// Step 1: Setup attack prerequisites
// Step 2: Execute attack
// Step 3: Assert attack effect (NOT just that tx succeeds)
assertGt(attackerProfit, 0, "Attack must produce profit");
}
}
Common Pitfalls
- vm.roll vs vm.warp:
vm.roll changes block number only, use vm.warp for timestamp
- StaleMessage: Some protocols check message freshness, set correct timestamp
- NotTolled/Payable: Auth functions may require fee payment (e.g.,
kiss())
- Unicode in Solidity: Replace
—, → etc. with ASCII
- Library paths: Check actual file location, not assumed paths
- Virtual shares/balance: Protocol-specific virtual accounting can absorb rounding (Morpho lesson)
- PASS ≠ correct: PoC passing doesn't mean finding is real — verify attack EFFECT, not just mechanism
Quality Self-Assessment Template
【提交前质量自评】
- Finding ID: [F-XX]
- Verification: [ ] Compiled [ ] forge test PASS [ ] Attack effect verified
- Severity: [H/M/L/I] — Rationale: [why this severity]
- Novelty: [New / Known / Duplicate] — Source if known: [link]
- Known limitations: [any caveats]
Level 2: GitHub CI (TODO)
Required Workflow
# .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
Purpose
Prevents Level 1 from being skipped due to session termination or memory loss.
Every push must pass forge test before PR can be submitted.
Level 3: Auditor Review
What auditors check (that forge test cannot)
- Novelty: Is this a known finding? Check previous audit reports
- Severity accuracy: Is Medium really Medium? (Sablier lesson: 2/5 overstated)
- Impact quantification: Precise loss calculation, not qualitative
- Report quality: Clear reproduction steps, code references, remediation
- Protocol economics: DeFi-specific game theory, incentive analysis
Pre-submission checklist
Severity Assessment Guide
| Severity | Criteria |
|---|
| HIGH | Direct fund loss, DoS of core function, permission escalation |
| MEDIUM | Indirect loss, constrained DoS, griefing with economic cost |
| LOW | Best practice violation, defense-in-depth, theoretical with no practical exploit |
| INFO | Code quality, documentation, no security impact |
Common overestimation: If impact requires multiple unlikely conditions, downgrade one level.
Common underestimation: If impact is systemic (affects all users), upgrade one level.
Lessons from Retrospective Verification (2026-03-31)
- 135 findings submitted, 0 verified → Cantina ban
- 29 findings retroactively verified: 28 real (96.6%), 1 FP (3.4%)
- Code analysis capability is solid; verification layer was missing
- False positive example: Morpho F-01 (virtual shares absorb rounding)
- Severity overestimation example: Sablier F-03, F-05 (Medium → Low)
- PoC compilation errors are normal, expect 2-3 rounds of fixes
- forge test PASS ≠ finding correct, verify attack EFFECT not just mechanism
