review-dependency-updates

name	review-dependency-updates
description	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'.

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:

   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. PR the result with a summary table - package, old→new, why it's safe (or why deferred).