cve-patcher

CVE Patcher

Orchestrates CVE vulnerability patching across one or many repositories. This is a launcher skill — it handles research and orchestration, then delegates the actual patching to dependency-patcher agents.

Step 1: Parse Input

Extract from the user's arguments:

• CVEs: Any argument matching CVE-\d{4}-\d{4,} (case-insensitive)
• Repos: If --repos is present, everything after it is a repository name. If not provided, auto-detect in Step 3.

Examples:

CVE-2024-38816 CVE-2024-22243
CVE-2024-38816 --repos my-api billing-service

Step 2: Research CVEs

For each CVE, use WebSearch to gather:

1. Package name and ecosystem (npm, Maven, pip, Go, Cargo, etc.)
2. Affected version range(s)
3. Fixed version(s) — the minimum version that resolves the vulnerability
4. Severity (CVSS score if available)
5. Whether the fix crosses a major version boundary

Research multiple CVEs in parallel using separate WebSearch calls in the same message.

Good queries: "CVE-XXXX-XXXXX" affected versions fix, NVD (nvd.nist.gov), GitHub Advisory Database.

Present a summary table to the user before proceeding:

| CVE              | Package          | Ecosystem | Affected         | Fix       | Severity | Major? |
|------------------|------------------|-----------|------------------|-----------|----------|--------|
| CVE-2024-38816   | spring-webmvc    | Maven     | < 6.1.13         | 6.1.13    | High     | No     |
| CVE-2024-22243   | spring-web       | Maven     | < 6.1.4          | 6.1.4     | Medium   | No     |

If any CVE requires a major version bump, flag it and ask the user how to proceed before continuing. Do not include major-bump CVEs in the agent dispatch unless the user approves.

Step 3: Detect Repositories

Determine the working context:

1. Single repo: Current directory has .git/ → patch it directly
2. Multi-repo folder: Current directory contains subdirectories that are git repos → patch all of them, or only those specified via --repos

For multi-repo with no --repos filter and more than 10 repos, list them and confirm with the user first.

Step 4: Read Settings

Check .claude/devline.local.md in each repo for CVE-specific verification settings:

CVE setting	Maps to	Default
cve_verify_build	dep_verify_build	true
cve_verify_tests	dep_verify_tests	true

Git workflow (branch, commit, push) is not configurable — CVE patching always follows the fixed workflow described in Step 5.

Step 5: Launch Dependency-Patcher Agents

Git workflow (applies to all modes)

Every dependency-patcher agent MUST follow this exact git workflow:

1. Checkout the default branch (detect with git symbolic-ref refs/remotes/origin/HEAD, fall back to main then master)
2. Pull latest (git pull)
3. Create a fix branch: fix/cve-[first-CVE-ID] (lowercase, e.g. fix/cve-2024-38816)
4. Apply the dependency updates (per kb-dependency-management)
5. Verify build and tests (per settings)
6. Commit with message: chore(deps): [comma-separated CVE IDs]
7. Do NOT push — the launcher handles delivery

Single-repo mode

Launch one dependency-patcher agent with:

Patch the following CVEs in this repository:

[CVE research table]

Repository: [absolute path]

Git workflow:
1. Checkout the default branch and pull latest
2. Create branch: fix/[first-CVE-ID]
3. Apply updates
4. Verify build/tests
5. Commit with message: chore(deps): [comma-separated CVE IDs]
6. Do NOT push — stop after committing

Settings: dep_auto_push=false, dep_branch_strategy=branch, [any verification overrides from devline.local.md]

Multi-repo mode

Launch one dependency-patcher agent per repository, all in parallel (background). Each agent gets:

• The full CVE research table
• Its specific repository path
• The git workflow instructions above (checkout default branch, pull, branch, update, verify, commit, NO push)
• That repo's verification settings

Wait for all agents to complete.

Step 6: Present Summary and Delivery Options

After all agents report back, compile a summary:

| Repository       | CVEs Patched           | CVEs Skipped (not affected) | Branch              | Issues     |
|------------------|------------------------|-----------------------------|---------------------|------------|
| my-api           | CVE-2024-38816         | CVE-2024-22243              | fix/cve-2024-38816  | —          |
| billing-service  | CVE-2024-38816, -22243 | —                           | fix/cve-2024-38816  | —          |
| auth-service     | —                      | CVE-2024-38816, -22243      | —                   | —          |
| legacy-app       | —                      | —                           | —                   | Tests fail |

If any repos had issues (test failures, verification errors), report them clearly before presenting options.

Then, for each repository that has successful patches, ask the user how they want to deliver the changes:

How would you like to deliver these changes?

1. **Create a PR** — push the branch and open a pull request (requires remote access)
2. **Squash merge locally** — squash-merge the fix branch into the default branch locally (no remote interaction)
3. **Exit** — leave the fix branch as-is and print the changes so you can handle it manually

Handling each option:

Option 1 — Create a PR:

• Push the fix branch: git push -u origin [branch-name]
• Create a PR using gh pr create with:
  • Title: chore(deps): patch [CVE IDs]
  • Body: the CVE research table and patch details
• Report the PR URL

Option 2 — Squash merge locally:

• Checkout the default branch
• Run git merge --squash [fix-branch]
• Commit with the same message: chore(deps): [CVE IDs]
• Delete the fix branch: git branch -d [fix-branch]
• Report: "Changes squash-merged into [default-branch]. Ready to push when you are."

Option 3 — Exit:

• Print a summary of what changed:
  • Branch name
  • Files modified (from git diff --stat [default-branch]..[fix-branch])
  • The commit(s) on the branch
• Report: "Fix branch [branch-name] is ready. You can push, merge, or cherry-pick manually."

In multi-repo mode, apply the same option to all repos unless the user requests per-repo handling.