← ClaudeAtlas

review-dependency-updateslisted

Review outdated dependencies, security-scan each candidate bump against OSV.dev, then apply only the safe updates and PR them. Use when asked to 'review dependency updates', 'what can/should be updated', 'are we exposed to <supply-chain attack>', 'bump dependencies safely'.
craigcossairt/trellis · ★ 3 · Code & Development · score 74
Install: claude install-skill craigcossairt/trellis
You are running a security-conscious dependency-update review. Nothing gets bumped blindly. The steps: 1. **List what's outdated.** Use the ecosystem's native command (`npm outdated`, `pub outdated`, `cargo outdated`, `pip list --outdated`, ...). Include pinned/held-back versions in the review, not just the auto-resolvable ones. 2. **Security-scan every candidate bump.** Use OSV.dev's `/v1/querybatch` REST API - it covers npm, pub, PyPI, crates.io, Go, and more, with no install required: ```bash curl -s -X POST https://api.osv.dev/v1/querybatch -d '{ "queries": [ {"package": {"name": "<pkg>", "ecosystem": "<npm|Pub|PyPI|crates.io>"}, "version": "<candidate-version>"} ] }' ``` For an active supply-chain scare, web-search the specific compromised packages and check the project's lockfiles for exposure. 3. **Categorize each dep:** safe-to-bump (well-aged, no advisories), hold (major/breaking - needs a code change), and blocked (open CVE, or freshly published - recently-published versions are the supply-chain risk; don't bump onto a release that's only days old). 4. **Apply only the safe set.** Edit the manifest, run install, then run lint + the test suite to confirm nothing broke. Don't bundle a breaking major into a routine bump - file it separately. 5. **Handle bot PRs (Dependabot/Renovate) the same way:** review each open PR against steps 2-3, merge the safe ones, leave breaking/suspect ones with a comment. 6. **