Conava Claude Devline Skills Cve Patcher

---
name: cve-patcher
description: "Patch CVE vulnerabilities across one or many repositories. Invoke with a list of CVEs and optionally specific repo names. Researches each CVE (affected package, ecosystem, versions), then launches dependency-patcher agents to update, verify, commit, and push. Use this skill whenever the user mentions CVEs, security vulnerabilities in dependencies, patching dependencies, or updating packages for security fixes — even if they don't say 'CVE' explicitly but reference a security advisory or vulnerable dependency."
argument-hint: "CVE-2024-XXXXX CVE-2024-YYYYY [--repos repo1 repo2]"
user-invocable: true
disable-model-invocation: false
---

# 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.