Dependency Audit

Skill: DEPENDENCY_AUDIT (Sui/Move)

Trigger Pattern: EXTERNAL_LIB flag (third-party Move dependencies detected in Move.toml beyond Sui framework) Inject Into: Breadth agents, depth-external Finding prefix: [DEP-N] Rules referenced: R1, R4, R8, R10

Move's dependency model is package-based: Move.toml declares dependencies with git URLs and revisions. Unlike EVM's compiled-and-deployed model where dependencies are inlined at compile time, Sui Move packages can depend on other PUBLISHED packages (on-chain) or source packages (compiled together). Third-party math libraries, utility packages, and protocol SDKs are common dependency vectors.

STEP PRIORITY: Steps 3 (Critical Function Audit, especially Step 4 Math Library Audit) and 5 (Shared Object Dependencies) are where HIGH/CRITICAL severity findings most commonly hide. The Cetus hack originated from a custom math library bit shift bug. Do NOT rush these steps.

Trigger Patterns

[dependencies]|git\s*=|subdir\s*=|rev\s*=|published-at|math|utils|library|helpers|common

Step 1: Dependency Inventory

Parse Move.toml and build a complete dependency tree. Categorize:

Trust classification:

• TRUSTED: Sui framework packages (sui, std). Audited by Mysten Labs, upgraded by validator governance. Minimal audit needed (but check for version-specific quirks).
• MUST_AUDIT: Third-party packages. MUST analyze critical functions used by the protocol.
• IN_SCOPE: Protocol's own packages. Full audit in main analysis.

Step 2: Package Immutability Check

For each third-party dependency, assess immutability and upgrade risk:

Source dependencies (compiled together):

• Pinned to specific git revision -> code is fixed at that commit. Safe from upstream changes.
• Pinned to a branch (e.g., main) -> upstream pushes automatically affect next compilation. FINDING: unpinned dependency.
• No rev field -> defaults to latest on default branch. Highest risk.

Published on-chain dependencies (referenced via published-at):

• Immutable package (UpgradeCap destroyed) -> behavior cannot change. Safe.
• Package with active UpgradeCap + compatible policy -> behavior CAN change.
• Your package pins to a specific version at compile time. If dependency publishes V2, you still use V1.
• Risk: When YOU upgrade (recompile), you may pull in dependency's latest version unknowingly.

Known upgrade history: Has the dependency been upgraded before? How many versions exist? Frequent upgrades indicate active development but also active change risk.

Checklist:

• Every third-party dependency is pinned to a specific git revision (not a branch)
• Published dependencies are either immutable or their upgrade policy is documented
• No dependency uses a latest or main branch reference

Step 3: Transitive Dependency Risk

Map the full dependency tree:

Transitive dependency risks:

• A -> B -> C: If C has vulnerability, A is affected even though A does not directly import C
• Version conflicts: If A depends on C v1 and B depends on C v2, Move compilation may fail. Sui resolves diamond dependencies by requiring all paths to agree on the same version.
• Transitive upgrade: If B upgrades and changes its dependency on C, your next recompile may pull different C code.

If Dep B upgrades, does it affect us through Dep A?

• Only if we recompile our package (Sui does not dynamically resolve dependencies)
• But: if Dep B is an on-chain published package that Dep A calls via CPI-equivalent, behavior changes immediately after Dep B upgrades

Step 4: Math Library Audit (CRITICAL -- Cetus Precedent)

Historical context: A major DeFi exploit targeted a bug in a custom bit shift helper function in a math library. This step is MANDATORY for any custom math/arithmetic library in the dependency tree.

For any custom math/arithmetic library dependency:

4a. Bit Shift Operation Audit (MR2)

Trace ALL bit shift operations (<<, >>) in the math library:

Move bit shift rules:

• << and >> do NOT abort if shift amount >= bit width -- they produce 0
• Custom bit shift helpers MUST validate shift amount < bit width
• If shift amount comes from user input or computation, it must be bounds-checked

Specific checks:

• Are ALL shift amounts validated to be < bit width of the operand type?
• Do custom bit shift helpers correctly handle edge cases (shift amount >= bit width, zero inputs, overflow)?
• Can intermediate computation produce a shift amount >= bit width?
• Are there any bit manipulation patterns that assume shift produces a specific non-zero result?

4b. Overflow/Underflow Audit

Move arithmetic safety:

• Default +, -, * abort on overflow/underflow -- safe
• But: custom math libraries may use bitwise operations to implement unchecked arithmetic for gas optimization
• as casts between integer types abort on overflow (e.g., (x as u64) where x > MAX_U64)
• Fixed-point: (a * b) / SCALE -- intermediate a * b may overflow u128 even if final result fits in u64

4c. Rounding and Precision

Check: For every division operation in the math library:

• Is rounding direction documented?
• Is rounding direction consistent with how the protocol uses the result?
• Can rounding errors accumulate across many operations?