Security-focused review of a dependency update. Use when reviewing dependency bumps, library upgrades, or evaluating a new dependency.
Security-focused review of a dependency update.
Argument: $ARGUMENTS — dependency name (e.g., github.com/lib/pq, express, tokio), optionally with version range (e.g., github.com/lib/pq 1.11.1..1.11.2). If empty, auto-detect from the current branch by diffing the dependency manifest against the main branch.
Detect the ecosystem and locate the manifest:
| Ecosystem | Manifest files |
|---|---|
| Go | go.mod, go.sum |
| Rust | Cargo.toml, Cargo.lock |
| Python | pyproject.toml, requirements*.txt, Pipfile.lock, poetry.lock |
| Node.js | package.json, package-lock.json, yarn.lock, pnpm-lock.yaml |
| Other | Identify automatically |
Diff the manifest against the base branch: package name, old version, new version, and any other dependency changes bundled in the same commit.
Run in parallel:
Create a session temp dir (if not already created) and clone the new version into it.
SESSION_DIR=$(mkdir -p /tmp/claude && mktemp -d /tmp/claude/XXXXXX)
Input validation: before using the package name in any shell command, validate it contains only alphanumerics, hyphens, underscores, dots, forward slashes, and @. Reject any input containing shell metacharacters (;, |, &, $, `, (, ), <, >, !, #, ~, {, }).
git clone --depth=100 --config core.hooksPath=/dev/null -- <upstream-repo-url> "$SESSION_DIR/<package-name>"
| Source | Method |
|---|---|
| OSV.dev | POST https://api.osv.dev/v1/query with package name and ecosystem |
| GitHub Advisory Database | gh api /advisories?ecosystem=<eco>&affects=<pkg> |
| NVD | Web search for package CVEs |
| Ecosystem-specific | govulncheck (Go), cargo audit (Rust), npm audit (Node), pip-audit (Python) |
| Web search | <package-name> CVE vulnerability security advisory |
Check for commonly confused similarly-named packages that may pollute search results.
Run after 2a and 2b complete — this cross-checks 2a's claimed changes against 2b's real commit history and diff, which is the first line of defense against a compromised or tampered release (the update itself may not be trustworthy, independent of whether the resulting code has exploitable bugs).
git rev-parse <tag>, compare against the release notes' linked commit or the registry's recorded commit hash where available). A moved tag pointing at a different commit than what was publicly reviewed is a known attack pattern.git log, git diff --stat against the prior version's ref) and flag anything not explained by the changelog or commit messages — especially changes with no corresponding entry at all.preinstall/postinstall/prepare in package.json, Python setup.py custom cmdclass/build_ext hooks, Makefile install targets, CI/release workflow files. These run with elevated trust and are a common injection point.Anything found here becomes explicit input to step 3 — surface the specific files/commits flagged so the audit reads them directly rather than re-discovering them independently.
Spawn a security-engineer-smythe agent to review the cloned source at $SESSION_DIR/<package-name>.
Apply the categories relevant to the library's purpose:
Network / Protocol libraries — TLS certificate validation and defaults, protocol message parsing and length validation, authentication mechanisms (password handling, token security), connection string / URL parsing injection, buffer safety and unbounded allocations from network data
Data access libraries — Query injection (SQL, NoSQL, LDAP, etc.), input escaping and parameterization, connection security defaults, credential exposure in errors or logs
HTTP libraries — SSRF and redirect following, header injection (CRLF), request smuggling, cookie security, response body size limits
Cryptographic libraries — Algorithm strength, CSPRNG usage, nonce/IV reuse, side-channel resistance, key management and zeroing
Serialization libraries — Deserialization attacks and type confusion, resource exhaustion (recursion bombs, billion laughs), malformed input handling
All libraries — Input validation and sanitization, memory safety and resource limits, error handling and information disclosure, concurrency safety (races, deadlocks), file system operations (path traversal, symlink attacks), transitive dependency risk, debug/logging modes that may leak sensitive data
Rate findings by emitting the three floats likelihood, impact, relevance per severity skill § 3 — never a hand-typed severity label; the pipeline derives the band from the floats, and a label authored alongside them drifts and is wrong by construction. This skill runs coordinator-inline (agent: claudius, context: fork) with no separate consolidation pass, so — like review-pr Pass C and check-pr-comments — it is the exception allowed to assign merge_class/intent_basis directly per severity skill § Merge Classification, in the v4 report JSON it emits (see claudius:report-format).
Include: file:line references, CWE IDs where applicable, impact, and remediation.
Spawn an architect-nagatha agent in parallel with step 3, to:
SECURITY.md presence, disclosure process, CVE registration discipline, maintainer activityAfter upstream review completes, assess how the dependency is used in our codebase:
This skill only produces and returns the report — it never posts anywhere. allowed-tools above has no GitHub comment/write tool; there is nothing here that could publish this report even if instructed to. Never describe the report as "posted" or "published" in any form — say "returned" or "written to <path>". The invoking skill or coordinator owns actually publishing it (see e.g. dependabot-merge § 5) and is responsible for verifying that publish actually happened (comment count/URL), not for trusting a self-report of success from whatever produced the text.
Present a single report:
Package, old version, new version, commit count, nature of changes (bug fix / feature / security fix / breaking change).
Whether the actual diff/commit history matches the documented changes (step 2d): tag/commit integrity result, and every undocumented, hidden, or otherwise suspicious file/commit/hook found — or state plainly that the diff fully matches what's documented. Treat any unresolved finding here as grounds to escalate the overall risk rating regardless of what the code-level audit (step 3) finds, since it calls the trustworthiness of the update itself into question, not just its code quality.
Table of CVEs/advisories found (or "None found"), affected versions, whether the new version is impacted. Note any commonly confused packages.
Table: Severity | Finding | Location | CWE — grouped by severity, CRITICAL first.
Table: Recommendation | Status | Action Needed? — for each finding, assess whether our usage is affected.
Numbered actionable items for our codebase, plus long-term considerations (e.g., migration to alternatives).
rm -rf "$SESSION_DIR"
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer