---
name: cve-impact
description: |
  **CRITICAL**: Use for ALL CVE discovery and listing. DO NOT call get_cves directly.

  Use when: "show critical CVEs", "CVEs on hostname X", "remediatable vulnerabilities", "impact of CVE-X", risk assessment.

  NOT for remediation (use `/remediation`).

  System-level: FIRST reply = pagination prompt (Step -1). Parsing: scripts/01-cve-response-parser.py.
model: inherit
color: blue
license: Apache-2.0
allowed-tools: vulnerability__get_cves vulnerability__get_cve vulnerability__get_cve_systems vulnerability__get_system_cves vulnerability__load_cve_dashboard inventory__find_host_by_name inventory__get_host_details
---

# CVE Impact Analysis Skill

This skill helps SREs analyze CVE vulnerabilities to understand their impact on systems before creating remediation playbooks.

**🚨 SYSTEM-LEVEL (CVEs on device X)**: Your **first reply** to the user MUST be the pagination prompt (Step -1). Do NOT call `inventory__find_host_by_name` or `vulnerability__get_system_cves` until the user responds. Do not validate MCP or resolve hostname first—HITL comes first.

**Integration with Remediation Skill**: The `/remediation` skill orchestrates this skill as part of its Step 1 (Impact Analysis) workflow for complex remediation scenarios. For simple standalone impact analysis, you can invoke this skill directly.

## Invocation Note (Host-Specific)

When invoked by another skill (e.g. remediation), use the Skill tool—do NOT use "Task Output" with the skill name as task ID. That causes "No task found with ID: cve-impact". See [skill-invocation.md](references/skill-invocation.md).

## Prerequisites

**Step 0 — Resolve scripts directory.** Before anything else, locate the helper scripts. They are inside the skill's `scripts/` subfolder. Run:
```bash
SCRIPTS_DIR="scripts"
test -f "$SCRIPTS_DIR/01-cve-response-parser.py" || { echo "Error: Scripts directory not found at $SCRIPTS_DIR"; exit 1; }
```
Use `$SCRIPTS_DIR` in all subsequent script calls.

**Required MCP Servers**: `lightspeed-mcp` ([setup guide](https://console.redhat.com/))

**Required MCP Tools**:
- `get_cves` (from lightspeed-mcp) - List/query CVEs by severity
- `get_cve` (from lightspeed-mcp) - Get specific CVE details
- `get_cve_systems` (from lightspeed-mcp) - Find systems affected by CVEs
- `get_system_cves` (from lightspeed-mcp) - List CVEs affecting a specific system (uses `system_uuid` only)
- `load_cve_dashboard` (from lightspeed-mcp) - Open the interactive CVE dashboard with query parameters. If the client does not support UI, the tool instructs the model to present the data as text.

**Required Environment Variables**:
- `LIGHTSPEED_CLIENT_ID` - Red Hat Lightspeed service account client ID
- `LIGHTSPEED_CLIENT_SECRET` - Red Hat Lightspeed service account secret

### Prerequisite Validation

**CRITICAL**: Before executing any operations, execute the `/mcp-lightspeed-validator` skill to verify MCP server availability.

**Validation freshness**: Can skip if already validated in this session..

**How to invoke**: Execute the `/mcp-lightspeed-validator` skill

**Handle validation result**:
- **If validation PASSED**: Continue with CVE impact analysis
- **If validation PARTIAL**: Warn user and ask to proceed
- **If validation FAILED**: Stop execution, provide setup instructions

## When to Use This Skill

**Use this skill directly when you need**:
- Standalone CVE impact analysis without remediation planning
- Quick risk assessment for a single CVE
- Understanding which systems are affected by a CVE
- CVE severity assessments for change management documentation
- Risk assessment reports for management

**Use the `/remediation` skill when you need**:
- CVE analysis followed by remediation playbook generation
- Complex workflows involving multiple CVEs and systems
- Integrated risk assessment + remediation planning + execution guidance
- Batch remediation across infrastructure
- End-to-end CVE management (analysis → validation → remediation → verification)

**To invoke**: Execute the `/remediation` skill

**How they work together**: The `/remediation` skill orchestrates this skill as part of its comprehensive workflow, combining impact analysis with context gathering, playbook generation, and execution guidance.

## Workflow

### Step -1: System-Level Gate — HITL FIRST (MANDATORY)

**If the user asked for CVEs on a device** (e.g. "CVEs on ip-172-31-32-201", "remediatable CVEs on hostname X", "most critical CVEs on system Y"):

**Your first response to the user MUST be the pagination prompt below. Do not run Step 0, do not call `inventory__find_host_by_name`, do not call `vulnerability__get_system_cves` until the user responds.**

Reply to the user with:

```
To fetch remediatable CVEs on this system, I will:
- Paginate through vulnerability__get_system_cves (limit=100 per page)
- Filter each page for advisory_available === true
- Systems often have 1,700+ CVEs (~18 API calls)

⚠️ First page only often returns 0 remediatable CVEs—they may be on any page. For "remediatable" queries, recommend "all pages".

Options:
- **First page only**: Fetch 100 CVEs, filter for remediatable (may be 0)
- **All pages**: Fetch until no more results (recommended for remediatable)
- **N pages**: Fetch up to N pages (e.g. "3 pages" = up to 300 CVEs scanned)

How would you like to proceed? (first page / all pages / N pages)
```

**Wait for the user to respond.** Only after they reply may you proceed to Step 0.

**If account-level** (e.g. "CVEs on my account"): Skip this step, go to Step 0.

---

### Step 0: Validate Lightspeed MCP Prerequisites

**Action**: Execute the `/mcp-lightspeed-validator` skill

**Note**: Can skip if validation was performed earlier in this session and succeeded..

**How to invoke**: Execute the `/mcp-lightspeed-validator` skill

**Handle validation result**:
- **If validation PASSED**: Continue to Step 1
- **If validation PARTIAL**: Warn user and ask to proceed
- **If validation FAILED**: Stop execution, user must set up MCP server

### Step 1: CVE Discovery — Choose Flow

Select the appropriate flow based on user request.

| Flow | When to Use | Flow File |
|------|-------------|-----------|
| **Account-level** | devices=all (account-wide CVEs) | [01-account-cves.md](references/flows/01-account-cves.md) |
| **System-level (all CVEs)** | devices=selected, remediation=does not matter | [02-system-all-cves.md](references/flows/02-system-all-cves.md) |
| **System-level (remediatable)** | devices=selected, remediation=available | [03-system-remediatable-cves.md](references/flows/03-system-remediatable-cves.md) |

**Variable mapping**:
- **devices**: all → account flow; selected → system flow
- **severities**: all, most critical, or selected → parameter/filter in each flow
- **remediation**: available → remediatable flow; does not matter → all-cves flow

---

#### CRITICAL: System-Level — HITL FIRST (Before Any Other Action)

**For system-level flows (02 or 03)**: Your **first** action MUST be to display the HITL prompt below and **wait for user confirmation**. Do NOT resolve hostname, do NOT call any MCP tool, until the user responds.

**Order of operations**:
1. **STOP. Display HITL prompt. Wait for user.**
2. Only after user confirms → document consultation → resolve hostname → call `vulnerability__get_system_cves`

*For remediatable CVEs on system (flow 03):*
```
To fetch remediatable CVEs on this system, I will:
- Paginate through vulnerability__get_system_cves (limit=100 per page)
- Filter each page for advisory_available === true
- Systems often have 1,700+ CVEs (~18 API calls)

⚠️ First page only often returns 0 remediatable CVEs—they may be on any page. For "remediatable" queries, recommend "all pages".

Options:
- **First page only**: Fetch 100 CVEs, filter for remediatable (may be 0)
- **All pages**: Fetch until no more results (recommended for remediatable)
- **N pages**: Fetch up to N pages (e.g. "3 pages" = up to 300 CVEs scanned)

How would you like to proceed? (first page / all pages / N pages)
```

*For all CVEs on system (flow 02):*
```
This system may have many CVEs. I will paginate through vulnerability__get_system_cves (limit=100 per page).

Options:
- **First page only**: Fetch 100 CVEs, then stop (quick overview)
- **All pages**: Fetch until no more results (systems with 1,700+ CVEs may require ~18 API calls)
- **N pages**: Fetch up to N pages (e.g. "3 pages" = 300 CVEs)

How would you like to proceed? (first page / all pages / N pages)
```

**Handle response**: Wait for user reply. Only after user confirms (and specifies strategy) may you proceed to resolve hostname and call `vulnerability__get_system_cves`. If user says "no" or cancels, stop execution.

**Anti-pattern**: Do NOT call `vulnerability__get_system_cves` or `inventory__find_host_by_name` before completing HITL. Calling with only the first page (limit=100, no offset loop) misses remediatable CVEs on later pages.

---

**Action**: Read and follow the selected flow file. For system-level, HITL is Step 1 (before all other steps).

### Step 2: CVE Information Retrieval (For Specific CVE Analysis)

**CRITICAL**: Document consultation MUST happen BEFORE tool invocation.

**Document Consultation** (REQUIRED - Execute FIRST):
1. **Action**: Read [cvss-scoring.md](references/cvss-scoring.md) using the Read tool to understand CVSS score interpretation and severity mapping
2. **Output to user**: "I consulted [cvss-scoring.md](references/cvss-scoring.md) to understand CVSS score interpretation and severity mapping."

**MCP Tool**: `get_cve` or `vulnerability__get_cve` (from lightspeed-mcp)

**Parameters**:
- `cve_id`: Exact CVE identifier from user query (format: `"CVE-YYYY-NNNNN"`)
  - Example: `"CVE-2024-1234"`
- `include_details`: `true` (retrieve complete metadata including CVSS vector, affected packages, references)

**Expected Output**: Comprehensive CVE metadata including CVSS score, severity, attack vector, affected packages, remediation status

Retrieve comprehensive CVE metadata:
```
CVE ID: CVE-YYYY-NNNNN
CVSS Score: X.X (Base score from NIST)
Severity: Critical/High/Medium/Low
Attack Vector: Network/Adjacent/Local/Physical
Attack Complexity: Low/High
Privileges Required: None/Low/High
User Interaction: None/Required
Scope: Unchanged/Changed
Confidentiality Impact: None/Low/High
Integrity Impact: None/Low/High
Availability Impact: None/Low/High

Description: [CVE description from NVD/Red Hat]
Affected Packages: [List of packages and versions]
Published Date: YYYY-MM-DD
Last Modified: YYYY-MM-DD
```

### Step 3: Affected Systems Identification

**CRITICAL**: Document consultation MUST happen BEFORE tool invocation.

**Document Consultation** (REQUIRED - Execute FIRST):
1. **Action**: Read [insights-api.md](references/insights/insights-api.md) using the Read tool to understand the system identification response format
2. **Output to user**: "I consulted [insights-api.md](references/insights/insights-api.md) to understand the system identification response format."

**MCP Tool**: `get_cve_systems` or `vulnerability__get_cve_systems` (from lightspeed-mcp)

**Parameters**:
- `cve_id`: Exact CVE identifier (format: `"CVE-YYYY-NNNNN"`)
  - Example: `"CVE-2024-1234"`
- `include_patched`: `false` (exclude already-patched systems to focus on vulnerable systems)

**Expected Output**: List of affected systems with UUID, hostname, IP address, package version, vulnerability status

Identify which systems in your infrastructure are affected by the CVE:
```
Affected Systems:
- system-uuid-1 (hostname: web-server-01, IP: 10.0.1.10)
  - Package: httpd-2.4.37-1.el8
  - Status: Vulnerable

- system-uuid-2 (hostname: web-server-02, IP: 10.0.1.11)
  - Package: httpd-2.4.37-1.el8
  - Status: Vulnerable

Total Affected Systems: N
```

### Step 4: System Classification

**CRITICAL**: Document consultation MUST happen BEFORE classification logic.

**Document Consultation** (REQUIRED - Execute FIRST):
1. **Action**: Read [fleet-management.md](references/insights/fleet-management.md) using the Read tool to understand system tagging and classification strategies
2. **Output to user**: "I consulted [fleet-management.md](references/insights/fleet-management.md) to understand system tagging and classification strategies."

Classify affected systems by environment and criticality based on tags from Red Hat Lightspeed:
```
System Classification:
- Production systems: N (highest priority)
- Staging systems: M (test before prod)
- Development systems: K (lowest priority)
- Bare metal: X systems
- Virtual machines: Y systems
```

### Step 5: Risk Assessment

**CRITICAL**: Document consultation MUST happen BEFORE risk assessment.

**Document Consultation** (REQUIRED - Execute FIRST):
1. **Action**: Read [cvss-scoring.md](references/cvss-scoring.md) using the Read tool to understand risk prioritization based on CVSS vectors
2. **Output to user**: "I consulted [cvss-scoring.md](references/cvss-scoring.md) to understand risk prioritization based on CVSS vectors."

Provide a risk assessment based on:
- CVSS score and severity
- Number of affected systems
- System criticality (production vs non-production)
- Attack vector and exploitability
- Known exploits in the wild

**Output Format**:
```
Risk Assessment Summary
━━━━━━━━━━━━━━━━━━━━━━━

Overall Risk Level: Critical/High/Medium/Low

Factors:
✓ CVSS Score: X.X (Severity: High)
✓ Affected Systems: N systems
✓ Environment: Production (Critical)
✓ Attack Vector: Network (Remote exploitable)
✓ Exploitability: Proof-of-concept exists
✓ User Interaction: None required

Recommendation: Immediate remediation recommended
Priority: P0 (within 24 hours) / P1 (within 7 days) / P2 (within 30 days)
```

### Step 6: Impact Analysis

Analyze business impact (service, confidentiality/integrity/availability, compliance).

### Step 7: Remediation Readiness Check

Check if automated playbook or manual steps are available.

## Output and Examples

**Read [references/03-output-templates.md](references/03-output-templates.md)** for report format.
**Read [references/04-examples.md](references/04-examples.md)** for query-type examples and remediation integration.

## Error Handling

**Read [references/05-error-handling.md](references/05-error-handling.md)** for CVE not found, no affected systems, and Lightspeed tool failures.

## Reference Files

| File | Use When |
|------|----------|
| [01-cve-response-parser.py](scripts/01-cve-response-parser.py) | Parse/filter MCP vulnerability responses |
| [02-cve-parsing-guide.md](references/02-cve-parsing-guide.md) | Parser invocation, filter options |
| [03-output-templates.md](references/03-output-templates.md) | Report format |
| [04-examples.md](references/04-examples.md) | Query-type examples |
| [05-error-handling.md](references/05-error-handling.md) | CVE not found, no systems, Lightspeed failures |
| [lightspeed-mcp-tool-failures.md](references/lightspeed-mcp-tool-failures.md) | explain_cves dnf_modules workaround |

## Parsing MCP Responses

**REQUIRED**: Use the skill's parser script for all vulnerability response parsing. Do NOT use jq, inline Python, or other ad-hoc JSON parsing.

**Do NOT generate inline Python** to aggregate multiple page files—the parser accepts multiple file paths and produces aggregated reports.

**Read** [references/02-cve-parsing-guide.md](references/02-cve-parsing-guide.md) for:
- Parser location: `$SCRIPTS_DIR/01-cve-response-parser.py`
- Single page: `python3 $SCRIPTS_DIR/01-cve-response-parser.py <response.json>`
- Multiple pages: `python3 $SCRIPTS_DIR/01-cve-response-parser.py page1.json page2.json page3.json ...` (merges, dedupes, aggregated report)
- Filter options: `FILTER_REMEDIATABLE=1`, `FILTER_IMPACT=Critical,Important`
- Report format: `OUTPUT=report`, `SYSTEM_NAME=hostname` for aggregated multi-page reports

Save each MCP tool result to a file, then run the parser with one or more paths. Use parser output for summary tables and reports.

## Best Practices

1. **Always start with risk assessment** before deciding on remediation
2. **Check for known exploits** using CVE description and references
3. **Consider business impact** not just CVSS scores
4. **Group related CVEs** for batch remediation when possible
5. **Document findings** for compliance and audit purposes
6. **Test in staging first** for high-impact changes

## Dependencies

### Required MCP Servers
- `lightspeed-mcp` - Red Hat Lightspeed platform access

### Required MCP Tools
- `get_cves` (from lightspeed-mcp) - List/query CVEs by severity and filters
  - Parameters: severity (array), sort_by (string), limit (number)
  - Returns: List of CVEs with CVSS scores, severity, affected systems count

- `get_cve` (from lightspeed-mcp) - Get specific CVE details
  - Parameters: cve_id (string, format CVE-YYYY-NNNNN), include_details (boolean)
  - Returns: Complete CVE metadata with CVSS vector, affected packages, references

- `get_cve_systems` (from lightspeed-mcp) - Find systems affected by CVE
  - Parameters: cve_id (string), include_patched (boolean)
  - Returns: List of affected systems with UUID, hostname, package version, status

- `get_system_cves` (from lightspeed-mcp) - List CVEs affecting a specific system
  - Parameters: **system_uuid** (string, required) - use `system_uuid`, NOT `system_id`
  - Does NOT support: impact, limit, severity filters - filter results client-side
  - Returns: List of CVEs affecting the system

- `load_cve_dashboard` (from lightspeed-mcp) - Open the interactive CVE dashboard
  - Parameters: Query parameters matching the data tool call (system_uuid, limit, sort, impact, advisory_available, etc.)
  - Returns: Interactive dashboard with CVE browsing, filtering, and drill-down
  - Falls back to text if unavailable or client does not support UI

### Related Skills
- `mcp-lightspeed-validator` - **PREREQUISITE** - Validates Lightspeed MCP server before operations
  - Use before: ALL cve-impact operations (Step 0 in workflow)
  - Purpose: Ensures MCP server is available before attempting tool calls

- `cve-validation` - Validate CVE IDs before impact analysis
  - Use before: Step 2 if CVE format/existence is uncertain
  - Purpose: Confirms CVE is valid and remediable before expensive analysis

- `system-context` - Get detailed system configuration after identifying affected systems
  - Use after: Step 3 when deeper system investigation is needed
  - Purpose: Understand deployment architecture for remediation planning

- `fleet-inventory` - Get comprehensive fleet information before CVE analysis
  - Use before: Step 1 when starting from fleet discovery
  - Purpose: Understand overall infrastructure before assessing CVE impact

### Reference Documentation
- [cvss-scoring.md](references/cvss-scoring.md) - CVSS score interpretation and severity mapping
- [vulnerability-logic.md](references/insights/vulnerability-logic.md) - CVE severity classification and filtering
- [insights-api.md](references/insights/insights-api.md) - System identification response format
- [fleet-management.md](references/insights/fleet-management.md) - System tagging and classification strategies
- [references/02-cve-parsing-guide.md](references/02-cve-parsing-guide.md) - Parse MCP vulnerability responses; use the parser script instead of generating inline Python

## Tools Reference

This skill primarily uses:
- `get_cve` (vulnerability toolset) - Get details about a specific CVE
- `get_cve_systems` (vulnerability toolset) - Get list of systems affected by a CVE
- `get_cves` (vulnerability toolset) - Get list of all CVEs affecting the account (optional)
- `get_system_cves` (vulnerability toolset) - Get list of CVEs affecting a specific system
  - **CRITICAL**: Use `system_uuid` (required), NOT `system_id`
  - Does NOT support `impact`, `limit`, or severity filters - filter client-side
- `inventory__find_host_by_name` (inventory toolset) - Resolve hostname to system UUID before get_system_cves
- `get_host_details` (inventory toolset) - Get detailed system information (optional)

All tools are provided by the lightspeed-mcp MCP server configured in `mcps.json`.