fix-vulnerability

Fix Vulnerability PR

Process a Snyk (or similar) dependency upgrade PR: rename the PR, regenerate the lockfile, analyze changelogs for breaking changes, and post a summary comment.

The user must provide a PR URL or number as $ARGUMENTS. If not provided, ask for it.

Step 1: Fetch PR details

Extract the PR number from the argument and fetch the PR diff to understand what changed:

# Get PR metadata
gh pr view <PR_NUMBER> --json number,title,body,headRefName,baseRefName

# Get the diff to see which dependencies changed
gh pr diff <PR_NUMBER>

Parse the diff to identify:

• Which packages were upgraded (package name, old version, new version)
• Which package.json files were modified
• Whether the lockfile (pnpm-lock.yaml) is included or missing

Report the list of dependency changes to the user before proceeding.

Step 2: Rename the PR

Replace the Snyk-generated title with a descriptive one following conventional commit format:

gh pr edit <PR_NUMBER> --title "fix: upgrade <package1> <oldVersion>→<newVersion> and <package2> <oldVersion>→<newVersion>"

Also update the PR description to append test trigger keywords so all test suites run on the next push:

# Get current body, append test keywords
CURRENT_BODY=$(gh pr view <PR_NUMBER> --json body -q '.body')
gh pr edit <PR_NUMBER> --body "${CURRENT_BODY}

test-frontend test-backend test-cli"

Rules for the title:

• Use fix: prefix (these are vulnerability fixes)
• List all upgraded packages with their version ranges
• If there are more than 3 packages, summarize: fix: upgrade 5 dependencies (security)
• Keep it under 72 characters when possible

Step 3: Checkout the PR branch and regenerate lockfile

# Fetch and checkout the PR branch
gh pr checkout <PR_NUMBER>

# Install dependencies to regenerate the lockfile (sfw blocks known-malicious packages)
# Requires `npm i -g sfw` to be installed globally once per machine.
sfw pnpm install

# Check if the lockfile was modified
git status pnpm-lock.yaml

If pnpm-lock.yaml was modified, stage and commit it:

git add pnpm-lock.yaml
git commit -m "chore: regenerate pnpm-lock.yaml

Co-Authored-By: Claude Opus 4.6 <[email protected]>"

Then push the changes:

git push

Step 4: Analyze changelogs for breaking changes

For each upgraded dependency identified in Step 1:

1. Fetch the changelog or release notes — try these sources in order: a. GitHub releases page: https://github.com/<owner>/<repo>/releases b. CHANGELOG.md in the repo: https://raw.githubusercontent.com/<owner>/<repo>/main/CHANGELOG.md c. npm page: https://www.npmjs.com/package/<package-name> d. Web search as a last resort: "<package-name> changelog <old-version> <new-version>"

2. Identify the package's GitHub repo from the PR body (Snyk usually includes repo links) or from npm registry metadata:

   npm view <package-name> repository.url
   

3. Review changes between the old and new versions. Focus on:

   • Breaking changes or deprecations
   • API changes that could affect our code
   • Major behavioral changes
   • Security advisories and CVE details

4. Search our codebase for usage of each upgraded package to assess impact:

   # Check how we import/use the package
   

   Use Grep to search for imports and usage patterns of each package across the codebase.

5. Assess risk for each dependency:

   • No risk: Patch version bump, no breaking changes, minimal usage in our code
   • Low risk: Minor version bump, no breaking changes in APIs we use
   • Medium risk: Breaking changes exist but don't affect our usage patterns
   • High risk: Breaking changes directly affect how we use the package

Step 5: Post PR comment with findings

Post a comment on the PR summarizing your analysis using gh pr comment:

gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
## Vulnerability Fix Analysis

### Lockfile
[✅ Regenerated and pushed / ℹ️ Already up to date]

### Dependency Changes

| Package | Old Version | New Version | Risk | Notes |
|---------|------------|-------------|------|-------|
| package-name | x.y.z | a.b.c | 🟢 No risk / 🟡 Low / 🟠 Medium / 🔴 High | Brief explanation |

### Breaking Changes Analysis

[For each dependency with notable changes, provide a brief summary]

#### `package-name` (x.y.z → a.b.c)
- **Changelog**: [link to changelog/releases]
- **Breaking changes**: [None / List of breaking changes]
- **Our usage**: [How we use this package, with file paths]
- **Impact**: [Assessment of whether breaking changes affect us]

### Recommendation
[Overall assessment: safe to merge, needs code changes, needs manual testing, etc.]

---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Adapt the comment content based on your actual findings. Be concise but thorough. If there are breaking changes that affect our code, clearly list what needs to change.

Step 6: Return to original branch

After posting the comment, switch back to the original branch:

git checkout main

Notes

• If pnpm install fails, report the error — it likely means the version bump introduced an incompatibility
• For monorepo packages (e.g., @types/*), check if the type changes affect our code
• Snyk PRs typically include CVE details in the PR body — reference these in your analysis
• If a dependency has many transitive dependents, note this as it increases risk surface
• Do NOT approve or merge the PR — only analyze and comment