plamentsv/dependency-audit-nodeclient

Injectable Skill: Node Client Dependency Audit

L1 trigger: L1_PATTERN=true — always runs Inject Into: Recon + any breadth agent Finding prefix: [DEP-N] Status: v0.1 draft, Round 4 exemplars pending

When This Skill Activates

Always active in L1 mode. Extends Plamen's existing dependency-audit skill with Go/Rust-specific checks relevant to node clients.

1. Go Module Audit

1a. Version check

• Read go.mod — identify every require line
• Check against Go vulnerability database: govulncheck ./... (ships with Go 1.18+)
• Check against OSV: https://osv.dev/
• Check against GitHub advisories for each dep

1b. Replace directive audit

• replace directives in go.mod can redirect a dep to a fork or local path
• Every replace is a trust statement: the audit must identify what's being replaced with what, and whether the replacement is authentic
• Fork audits: the target likely has replace pointing to the parent client (e.g., replace github.com/ethereum/go-ethereum => github.com/ethereum-optimism/op-geth v1.x.y)
• Flag every replace with an explicit note in the finding

Tag: [GO-REPLACE:{original}:{replacement}:{trust-note}]

1c. vendor/ directory

• If the target uses vendor/, check if vendored code matches upstream. Modified vendored deps are a red flag.
• Run go mod verify if possible to check checksums

Tag: [GO-VENDOR-DIFF:{module}]

1d. Indirect dependency bloat

• Excessive transitive deps increase the attack surface
• For each // indirect line, ask: is the intermediate dep actually used?

2. Rust Cargo Audit

2a. Version check

• cargo audit (requires the cargo-audit tool; install with cargo install cargo-audit)
• Reads Cargo.lock against the RustSec advisory database (https://rustsec.org/)
• cargo deny for richer policy (denylist, license, trust)

2b. Patch directive audit

• [patch.crates-io] and [patch."https://..."] blocks in Cargo.toml and workspace root
• Same trust concern as Go replace: patches redirect deps
• Fork audits: likely patches pointing to parent client

Tag: [RS-PATCH:{original}:{replacement}:{trust-note}]

2c. Git dependencies

• { git = "https://..." } in Cargo.toml bypasses crates.io review
• Pin to specific commit (rev = "...") not branch; branches move
• For each git dep: is the commit SHA pinned? Is the repo authentic?

Tag: [RS-GIT-DEP:{crate}:{rev-pinned}]

2d. Workspace structure

• Multi-crate workspace: workspace.members lists crates
• Each workspace crate can have its own dependency set
• Run cargo audit at the workspace root, not per-crate

3. Supply Chain Red Flags

Patterns that warrant deeper review across both ecosystems:

1. Typosquatting: check for dep names that are one character off common names (e.g., tokio-util vs tokio-utils)
2. Recently created deps with large version numbers: 1.0.0 published 2 weeks ago is suspicious
3. Deps maintained by a single individual with no org backing: not a bug per se, but worth flagging for critical-path deps
4. Deps with obvious abandonment signals: last commit >2 years ago on a security-critical dep
5. Deps with known compromises: cross-reference against the event-stream / ua-parser-js / xz-utils class of events

Tag: [SUPPLY-CHAIN:{dep}:{concern}]

4. L1-Specific Critical Path Deps

These deps are security-critical for L1 clients and deserve extra scrutiny:

Go L1 critical deps

• github.com/ethereum/go-ethereum (if fork)
• github.com/cosmos/cosmos-sdk
• github.com/cometbft/cometbft
• github.com/libp2p/*
• github.com/holiman/uint256
• github.com/syndtr/goleveldb
• Any crypto lib: golang.org/x/crypto, github.com/consensys/gnark-crypto

Rust L1 critical deps

• reth-* crates (if fork)
• alloy-* (Ethereum types)
• revm (EVM impl)
• libp2p
• blst / bls12_381
• secp256k1
• tokio (async runtime)
• rocksdb (storage)
• arkworks-* (crypto)

For each of these in the target, report: version, whether it's current, any recent advisories.

5. Version Pinning Hygiene

• Exact pins (1.2.3) vs ranges (^1.2, ~1.2): ranges allow drift on rebuild
• Cargo.lock in version control: required for reproducibility (applications always commit; libraries traditionally don't)
• go.sum in version control: required for reproducibility

Tag: [VERSION-DRIFT:{dep}:{pin-status}]

6. Output schema

• Layer: dependency
• Bug class: known-vuln / replace-trust / patch-trust / supply-chain / version-drift
• Preferred evidence tags: [TOOL-PASS] (govulncheck / cargo-audit output) > [CODE-TRACE]
• Severity: depends on the specific advisory; typically Low to Medium for outdated deps, High for active-vuln deps in critical path

6b. Known bug exemplars (v0.2 — Round 4 verified)

1. BNB Chain bridge $100M+ loss (October 2022) — root cause: unmaintained IAVL Merkle proof library consumed by the BNB bridge. Dragonberry-class verification flaw in the shared library. Single unmaintained dependency, catastrophic impact. Halborn writeup. Skill catch point: Section 3 — unmaintained cryptographic library flag. Last commit >2 years ago on a security-critical dep = automatic finding.

2. Moonbeam / Astar / Acala shared paritytech/frontier bug (~$200M at risk, 2022-2023) — single shared dependency blew up across 3 projects. The Immunefi $1M bugfix review covers the initial Moonbeam discovery; Zellic re-discovered the same class in Astar 18 months later after the library was patched. Immunefi Moonbeam/Astar/Acala review; Zellic Astar. Skill catch point: Section 4 — produce a reverse-dependency graph of the core crypto/VM libraries. Any library that, if compromised, would affect ≥2 L1/L2 networks is a critical-review target.

3. Avalanche RFC6979 Decred library reuse (disputed, 2022) — ava-labs/avalanchego used a Decred library for deterministic signing; cross-project library reuse where an upstream bug can leak into downstream consensus. coingeek report. Skill catch point: Section 4 — every upstream Go module with network/crypto/consensus relevance needs CVE-history and maintainer-response-time check.

7. Fallback if primitives unavailable

• Read go.mod and go.sum manually
• Read Cargo.toml and Cargo.lock manually
• Check https://osv.dev for each top-level dep
• Use gh api to check GitHub security advisories for each repo

Cross-references

• Extends Plamen's existing dependency-audit skill
• Related: All L1 skills — deps are foundational
• Consumed by: recon agent, every breadth agent