# Resolve Cve

> Resolve Cve is an Agent Skill for devops & security published in the opensearch-project/OpenSearch-Dashboards repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

Automatically resolve CVEs by checking GitHub issues, verifying presence in codebase, and attempting various remediation strategies while documenting the process.

- Skill name: `resolve_cve`
- Category: [DevOps & Security](https://www.openparable.com/skill/devops-security/1)
- Source: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/HEAD/.claude/skills/resolve_cve/SKILL.md
- Repository: opensearch-project/OpenSearch-Dashboards (2,093 GitHub stars when collected)

## SKILL.md

# CVE Resolution Skill

Automatically resolve CVEs by checking GitHub issues, verifying presence in codebase, and attempting various remediation strategies while documenting the process.

## Usage

```
/resolve-cve [--cve_id CVE-2024-12345]
```

If no CVE ID is provided, will search for all open CVE issues.

## Process

You are a CVE resolution specialist for OpenSearch Dashboards. Your goal is to automatically identify and resolve security vulnerabilities in the project's dependencies.

**Important**: 
- Always create reports in `tmp/` directory (gitignored) to avoid committing temporary files
- Clean existing tmp files at start of each run to prevent stale data in PR descriptions

### Step 1: Identify CVEs

1. **Search GitHub Issues**: Look for open CVE issues in https://github.com/opensearch-project/OpenSearch-Dashboards/issues

   - Use GitHub API or web search to find issues with "CVE" in title
   - Filter for open issues only
   - Extract CVE numbers and affected package information

2. **Parse CVE Details**: For each CVE found, extract:
   - CVE identifier (e.g., CVE-2024-12345)
   - Affected package name and vulnerable version range
   - Recommended safe version
   - Severity level

### Step 2: Verify Presence in Codebase

1. **Check package.json**: Search for the vulnerable package in package.json files
2. **Check yarn.lock**: Verify if vulnerable versions are actually installed
3. **Analyze dependency tree**: Use `yarn why <package>` to understand why the package is included

### Step 3: Remediation Strategies

Try the following strategies in order until successful:

#### Strategy A: Direct Package Update (if in package.json)

1. If vulnerable package is explicitly declared in package.json:
   - Update version to safe version with caret (^)
   - Run `yarn osd bootstrap` to update lock file and verify build

#### Strategy B: Lock File Manipulation (if transitive dependency)

1. If package is NOT in package.json (transitive dependency):
   - Delete vulnerable package entries from yarn.lock
   - Run `yarn osd bootstrap` to regenerate with latest versions
   - Check if vulnerability is resolved

#### Strategy C: Peer Dependency Resolution

1. If Strategy B fails due to peer dependency constraints:
   - Identify which dependency requires the vulnerable version
   - Delete that dependency's yarn.lock entries too
   - Run `yarn osd bootstrap` again
   - May need to update parent dependency version

#### Strategy D: Resolutions (last resort)

1. If other strategies fail:
   - Add yarn resolutions to package.json to force safe version
   - Use the least invasive resolution path possible
   - Example: If package "a" has a CVE and the vulnerable version comes from dependency "b", use a targeted resolution like `"**/b/a": "^3.5.3"` instead of a global `"a": "^3.5.3"`
   - Document why the resolution was needed and which dependency path required it

### Step 4: Verification

After each remediation attempt:

1. Run `yarn osd bootstrap` to ensure build succeeds
2. Run `yarn audit` to check if vulnerability is resolved
3. Run basic smoke tests if available
4. Verify no new vulnerabilities were introduced

### Step 5: Documentation

Create a PR-ready description in `tmp/cve-pr-description.md` by **dynamically using the current GitHub PR template**:

1. **Read the current PR template**: Load `.github/pull_request_template.md` to get the latest format
2. **Parse template structure**: Identify sections like Description, Issues Resolved, Testing, etc.
3. **Fill in CVE-specific content**: Replace template placeholders with actual CVE resolution details
4. **Auto-extract GitHub Issue Numbers**: Parse CVE issue URLs and add `closes #[number]` entries

**Content Mapping Strategy**:

- **Description section**: Fill with CVE summary, affected packages, resolution strategy
- **Issues Resolved section**: Auto-populate with `closes #[issue-number]` from found CVE issues
- **Testing section**: Add CVE-specific verification commands
- **Checklist section**: Mark relevant items as completed based on resolution results

**Dynamic Template Approach**:

```bash
# Always use current template as base
cp .github/pull_request_template.md tmp/cve-pr-description.md

# Then programmatically fill in sections with CVE data:
# - Replace "<!-- Describe what this change achieves-->" with CVE details
# - Replace "<!-- List any issues this PR will resolve -->" with closes #123
# - Fill testing section with CVE verification steps
```

This ensures the skill **always respects the current PR template format**, even if it changes in the future - no manual skill updates required!

### Step 6: Setup and Failure Documentation

**Setup tmp/ directory and generate PR description**:

```bash
mkdir -p tmp
echo "tmp/" >> .gitignore  # if not already present

# IMPORTANT: Clean any existing tmp files to avoid stale data
rm -f tmp/cve-pr-description.md tmp/cve-failure-report.md

# Use current GitHub PR template as base (future-proof!)
cp .github/pull_request_template.md tmp/cve-pr-description.md
```

**Why we clean tmp files first**:
- **Prevents stale data**: Ensures fresh reports with current CVE status
- **Accurate issue refs**: Avoids outdated "closes #123" references  
- **No confusion**: Eliminates mixing data from multiple CVE runs
- **Current state**: Always reflects the actual dependency versions being fixed

**Template Content Replacement Guide**:

1. **Description section**: Replace `<!-- Describe what this change achieves-->` with:

   ```
   Resolves security vulnerabilities in project dependencies:
   - **CVE-[ID]** ([Severity]): [Brief description]
   - **Package**: [affected-package@version] → [safe-version]
   - **Resolution Strategy**: [Strategy used]
   ```

2. **Issues Resolved section**: Replace `<!-- List any issues... -->` with:

   ```
   - closes #[issue-number]  (auto-extracted from GitHub CVE issues)
   ```

3. **Testing section**: Replace `<!-- Please provide detailed steps... -->` with CVE-specific validation steps

This approach ensures the skill **automatically adapts** to any future PR template changes without requiring skill updates.

If CVE cannot be automatically resolved, document in `tmp/cve-failure-report.md`:

- Which strategies were attempted
- Specific error messages encountered
- Dependency conflicts preventing resolution
- Recommended manual intervention steps
- Upstream dependency update requirements
- GitHub issue numbers for tracking

## Error Handling

- Always backup original package.json and yarn.lock before making changes
- If any step fails, restore backups and document the failure
- Never leave the project in a broken state
- Provide clear next steps for manual resolution

## Constraints

- Only modify dependency versions, never remove required dependencies
- Maintain compatibility with Node.js version requirements
- Preserve existing functionality
- Follow semver best practices for version updates
- Document all changes for PR review

## Success Criteria

A CVE is considered resolved when:

1. Vulnerable package version is no longer present
2. Project builds successfully (`yarn osd bootstrap` passes)
3. All tests pass (`yarn test:jest` passes)
4. No new vulnerabilities introduced (`yarn audit` clean for resolved CVE)
5. PR-ready documentation created in `tmp/cve-pr-description.md`
6. GitHub issue numbers auto-extracted and added as `closes #123` references

## Output Files

- `tmp/cve-pr-description.md` - PR description ready to copy/paste, **dynamically generated from current `.github/pull_request_template.md`**
- `tmp/cve-failure-report.md` - Failure analysis (if resolution fails), using same template approach
- Both files automatically adapt to future PR template changes - no skill maintenance required!

---

Source: https://www.openparable.com/skill/devops-security/resolve-cve (OpenParable). Cite the canonical URL above.