audit-breadth-scan

name	audit-breadth-scan
description	Use when performing systematic breadth-first review of all contracts during a security audit. Covers contract-by-contract review, function-level risk assessment, attack surface mapping, and identifying leads for depth analysis.

Audit Breadth Scan

Purpose

The breadth scan is a systematic, contract-by-contract review that ensures every function is examined at least once. The goal is NOT to find every bug — it's to identify high-risk areas that warrant depth analysis.

Methodology

Pass 1: Contract-Level Assessment

For each contract in scope, assess:

## [Contract Name] — Breadth Assessment

### Overview
- Lines of code: X
- Inheritance chain: A -> B -> C
- State variables: Y
- External calls: Z

### Complexity Rating: [Low | Medium | High | Critical]
Factors: math complexity, external interactions, state machine logic,
         upgrade mechanics, cross-contract dependencies

### Initial Risk Notes
- [Any patterns that stand out]

Pass 2: Function-Level Risk Assessment

Rate each function on a risk matrix:

Risk Factor	Weight	Criteria
External calls	High	Calls to untrusted contracts
State changes	Medium	Modifies critical state (balances, shares)
Math operations	Medium	Division, multiplication with large numbers
Access control	High	Missing or incorrect
Value transfer	Critical	ETH or token movement
User input	Medium	Complex parameter handling

### Function Risk Matrix

| Function | External Calls | State Change | Math | Value Transfer | Risk |
|----------|---------------|--------------|------|----------------|------|
| deposit() | transferFrom | balances, supply | share calc | tokens in | HIGH |
| withdraw() | transfer, strategy | balances, supply | share calc | tokens out | CRITICAL |
| setFee() | none | fee param | none | none | LOW |
| harvest() | aave.withdraw | deployed amount | yield calc | tokens move | HIGH |

Pass 3: Attack Surface Mapping

For each high/critical risk function, map potential attack vectors:

### Attack Surface: withdraw()

**Preconditions**: User has shares, vault has assets

**Attack Vectors**:
1. Reentrancy via token callback (ERC777, hooks)
   - Mitigation: ReentrancyGuard
   - Status: CHECK if guard applied

2. Share price manipulation
   - Donate tokens to inflate totalAssets before withdraw
   - Status: CHECK virtual shares mitigation

3. Front-running
   - Sandwich attack around large withdrawals
   - Status: CHECK slippage protection

4. Oracle manipulation
   - Stale/manipulated price affects withdrawal amount
   - Status: CHECK staleness validation

5. Integer overflow/underflow
   - Share calculation edge cases
   - Status: CHECK Solidity 0.8 overflow protection

Common Vulnerability Patterns to Check

High Priority

□ Reentrancy (state changes after external calls)
□ Access control missing or bypassable
□ Oracle manipulation / stale prices
□ Flash loan attack vectors
□ Integer overflow in unchecked blocks
□ First depositor / share inflation attacks
□ Frontrunning / sandwich attacks
□ Unauthorized token approvals
□ Improper input validation

Medium Priority

□ Centralization risks (owner can rug)
□ Denial of service (gas griefing, reverts)
□ Rounding errors favoring attacker
□ Event emission correctness
□ Return value handling (unchecked transfers)
□ Storage collision (proxies)
□ Signature replay / malleability
□ Block timestamp dependence

Low Priority

□ Gas optimization opportunities
□ Code quality / readability
□ Missing error messages
□ Unused variables / imports
□ Inconsistent naming
□ Missing NatSpec documentation

Breadth Scan Report Template

For each contract:

## Vault.sol — Breadth Scan

### Functions Reviewed: 12/12
### Risk Rating: HIGH

### Findings (leads for depth)
| ID | Function | Pattern | Confidence | Depth Priority |
|----|----------|---------|------------|----------------|
| B-01 | withdraw | Possible reentrancy before state update | Medium | P0 |
| B-02 | deposit | No check for zero shares | High | P1 |
| B-03 | harvest | Unchecked return value from strategy | Medium | P1 |
| B-04 | setOracle | No timelock on oracle change | High | P2 |

### Clean Areas (no further review needed)
- Constructor: correctly initializes all state
- View functions: no state modifications
- Pause mechanism: standard OZ implementation

Timing Guidelines

Project Size	Breadth Time	Depth Time	Report
< 500 SLOC	2-4 hours	4-8 hours	2 hours
500-2000 SLOC	1-2 days	2-4 days	1 day
2000-5000 SLOC	2-3 days	4-6 days	1-2 days
> 5000 SLOC	3-5 days	5-10 days	2-3 days

Transition to Depth Analysis

After breadth scan, prioritize depth analysis leads:

• P0: Likely vulnerability, high impact → analyze immediately
• P1: Suspicious pattern, needs verification → analyze next
• P2: Possible issue, lower impact → analyze if time permits
• P3: Informational / optimization → include in report as-is

Checklist

• Every contract in scope reviewed
• Every external/public function risk-assessed
• Attack surfaces mapped for high-risk functions
• Common vulnerability patterns checked against each contract
• Depth analysis leads prioritized (P0-P3)
• Clean areas documented (saves time later)
• Breadth scan notes organized per contract
• Automated tool findings cross-referenced with manual review