Skill: DEPENDENCY_AUDIT
Trigger: EXTERNAL_LIB flag detected (protocol uses third-party Move dependencies)
Used by: Breadth agents, depth-external
Covers: Third-party library security, upgrade policy risks, critical function correctness, transitive dependency chains
Purpose
Audit third-party Move dependencies for security risks. Aptos protocols commonly depend on external math libraries, utility modules, and protocol SDKs. Unlike EVM (where dependencies are compiled into the contract), Move dependencies are on-chain modules that can be independently upgraded. A dependency upgrade can silently change the behavior of the audited protocol.
Methodology
STEP 1: Dependency Inventory
Parse Move.toml for all dependencies. Categorize each:
Categories:
- FRAMEWORK:
aptos_framework, aptos_std, aptos_token, aptos_token_objects - trusted, framework-governance-controlled. Audit framework USAGE, not framework internals.
- THIRD_PARTY: External libraries (math utils, oracle SDKs, DEX interfaces). MUST audit all called functions.
- IN_SCOPE: Protocol's own sub-modules. Fully in scope.
MANDATORY PARSE: Read Move.toml (and any sub-package Move.toml files) for:
[dependencies] section entries
git = "..." URLs - identify the source repository
rev = "..." - pinned revision hash (safe) vs branch = "main" (dangerous)
local = "..." - in-scope sub-modules
STEP 2: Upgrade Policy Risk Assessment
For each THIRD_PARTY dependency:
Check for each compatible dependency:
- Can the dependency publisher add new friend declarations (giving new modules access to internal state)?
- Can the dependency publisher change function implementations (same signature, different logic)?
- Can the dependency publisher add new public functions that interact with stored state?
- Does the audited protocol store any state that the dependency module can access?
- Is there a governance/multisig controlling the dependency's publisher address?
Severity: If a compatible third-party dependency can be upgraded to change behavior of functions the protocol calls, AND the protocol has no way to detect or prevent this -> minimum MEDIUM finding.
Pinning check: If Move.toml uses branch = "main" instead of rev = "abc123":
- Build reproducibility is broken
- Developer may unknowingly compile against a different version
- Document as INFO finding (build hygiene)
STEP 3: Critical Function Audit
For each function called from a THIRD_PARTY dependency:
3a. Function Inventory
3b. Correctness Verification
For each critical function (called frequently OR high impact if wrong):
Overflow/underflow check:
- Does the function handle multiplication overflow? (e.g.,
a * b where both are u64 - can overflow)
- Does it handle division by zero?
- Does it use intermediate u128 for precision in u64 arithmetic?
- Bit shift safety: Does it use
<< or >>? If so, is the shift amount bounded to < 64 (for u64) or < 128 (for u128)? Unbounded bit shifts are a known attack vector (historical exploit: bit shift overflow in a custom shift helper allowed minting tokens from minimal liquidity).
Edge case check:
Specification check:
- Does the function have documented behavior? (comments, spec blocks)
- Does the implementation match the specification?
- If the function is a math operation: verify against a reference implementation or mathematical formula