audit-recon

name	audit-recon
description	Use when performing initial audit reconnaissance. Covers automated tooling, dependency review, architecture mapping, entry point identification, trust boundary mapping, external call enumeration, and access control analysis.

Audit Reconnaissance

Phase Overview

Recon is the first phase of a security audit. The goal is to build a mental model of the system before diving into code. Spend 10-20% of total audit time here.

Step 1: Automated Tools First

Run automated scanners to identify low-hanging fruit and build familiarity:

# Slither — static analysis
slither . --filter-paths "test|script|node_modules" \
    --print human-summary \
    --print contract-summary

# Aderyn — Solidity-specific linter
aderyn . --exclude test/ --output aderyn-report.md

# Solidity Metrics — complexity and SLOC
solidity-metrics src/

# Dependency tree
forge tree

Slither Detectors to Focus On

Detector	Severity	What It Finds
reentrancy-eth	High	ETH reentrancy
reentrancy-no-eth	Medium	State reentrancy
unchecked-transfer	High	Unchecked ERC20 returns
arbitrary-send-eth	High	Uncontrolled ETH transfer
suicidal	High	Unprotected selfdestruct
uninitialized-state	High	Uninitialized variables
controlled-delegatecall	High	User-controlled delegatecall

Slither Printers for Recon

# Call graph
slither . --print call-graph

# Function summary (visibility, modifiers, state changes)
slither . --print function-summary

# Inheritance graph
slither . --print inheritance-graph

# Variables read/written per function
slither . --print vars-and-auth

Step 2: Dependency Review

# List all dependencies and versions
forge tree

# Check for known vulnerabilities
# Cross-reference OpenZeppelin version against security advisories
# https://github.com/OpenZeppelin/openzeppelin-contracts/security/advisories

Key questions:

• Are dependencies pinned to specific commits/versions?
• Any modified/forked dependencies?
• Solidity compiler version — known compiler bugs?

Step 3: Architecture Mapping

Build this map by reading code, starting from entry points:

## Contract Map

### Core
- Vault.sol (512 SLOC) — main entry point
  - Inherits: ERC4626, Ownable, ReentrancyGuard, Pausable
  - External calls: Strategy, Oracle, USDC
  - State: deposits, withdrawals, share pricing

### Periphery
- Strategy.sol (189 SLOC) — yield deployment
  - External calls: Aave Pool, USDC
  - Called by: Vault (only)

### Libraries
- MathLib.sol (45 SLOC) — fixed-point math
  - Pure functions, no state

Step 4: Entry Point Identification

Map every external and public function with their access control:

## Entry Points

| Contract | Function | Access | State Changes | Risk |
|----------|----------|--------|---------------|------|
| Vault | deposit(uint256,address) | Anyone | balances, totalSupply | Medium |
| Vault | withdraw(uint256,address,address) | Owner/approved | balances, totalSupply | High |
| Vault | setStrategy(address) | Owner only | strategy | Critical |
| Vault | pause() | Owner only | paused flag | Low |
| Strategy | harvest() | Keeper only | deployed amount | Medium |
| Strategy | emergencyWithdraw() | Owner only | all state | Critical |

Step 5: Trust Boundary Mapping

## Trust Boundaries

### Fully Trusted
- Owner multisig (can change parameters, pause, upgrade strategy)
- Timelock controller (executes governance decisions)

### Semi-Trusted
- Keeper bot (can trigger harvest, but cannot steal funds)
- Oracle feeds (Chainlink — trusted but can go stale)

### Untrusted
- End users (deposit/withdraw — fully adversarial)
- External protocols (Aave — could be exploited)
- Token contracts (USDC — could blacklist)

### Attack Surfaces by Trust Level
1. Untrusted user -> Vault: reentrancy, share manipulation, front-running
2. Stale oracle -> Vault: incorrect valuations, over-borrowing
3. Compromised keeper -> Strategy: timing attacks on harvest
4. External protocol exploit -> Strategy: loss of deployed funds

Step 6: External Call Mapping

Every external call is a potential vulnerability vector:

## External Calls

| Source | Target | Function | Untrusted? | Risk |
|--------|--------|----------|------------|------|
| Vault | USDC | transferFrom | No (known) | Low |
| Vault | Strategy | deploy | No (owned) | Low |
| Strategy | Aave Pool | supply | Semi | Medium |
| Strategy | Aave Pool | withdraw | Semi | Medium |
| Oracle | Chainlink | latestRoundData | Semi | Medium |

Step 7: Access Control Enumeration

# Use Slither to enumerate access controls
slither . --print vars-and-auth

# Manually verify:
# 1. Every onlyOwner function is truly admin-only
# 2. No function missing access control that modifies state
# 3. Initializer functions protected against re-initialization
# 4. Constructor sets correct initial values

Recon Report Template

# Audit Recon Report — [Protocol Name]

## Summary
- **Total SLOC**: X
- **Contracts in scope**: Y
- **External dependencies**: Z
- **Compiler**: solc X.Y.Z

## Architecture Diagram
[Mermaid or text diagram]

## Entry Points (sorted by risk)
[Table from Step 4]

## External Calls
[Table from Step 6]

## Trust Boundaries
[From Step 5]

## Automated Tool Findings
- Slither: X high, Y medium, Z low (after triage)
- Aderyn: X findings

## Initial Leads for Depth Analysis
1. [Finding/area that needs deeper review]
2. [Suspicious pattern identified]
3. [Complex logic requiring manual review]

Checklist

• Slither run with findings triaged (true/false positive)
• Aderyn run reviewed
• Dependency versions checked against known vulnerabilities
• All entry points mapped with access controls
• External calls enumerated and risk-assessed
• Trust boundaries documented
• Architecture diagram created
• Initial depth-analysis leads identified
• Recon report completed before moving to breadth scan