Coreos Cve Validator

---
name: coreos-cve-validator
description: Validate a CVE against Red Hat Enterprise Linux CoreOS (RHCOS) in a specific OCP release by extracting RPM packages and checking Red Hat VEX data.
license: Apache-2.0
user_invocable: true
model: inherit
color: red
---

# CoreOS (RHCOS) CVE Validator

## When to Use This Skill
Use this skill when the user asks you to check, validate, or analyze a CVE against Red Hat Enterprise Linux CoreOS (RHCOS) for a specific OpenShift Container Platform (OCP) version. CoreOS is the immutable OS running on OCP nodes.

## Input

Two required inputs:
- **CVE ID** — format `CVE-YYYY-NNNNN`
- **OCP version** — format `4.X.Y` (e.g., `4.20.17`)

## Prerequisites

**Resolve scripts directory** — the helper scripts are at `../scripts/` relative to this project's root:
```bash
SCRIPTS_DIR="$(git rev-parse --show-toplevel)/ocp-admin/scripts/security-validation"
test -f "$SCRIPTS_DIR/validate_input.py" || { echo "Error: Scripts directory not found at $SCRIPTS_DIR"; exit 1; }
```
The scripts check internally for `oc` and `podman`.

## Workflow

**MANDATORY EXECUTION CONTRACT:**

| # | Step | Required | May skip only when |
|---|---|---|---|
| 1 | Input validation | Always | Never |
| 2 | CVE Reconnaissance | Always | Never |
| 3 | CoreOS metadata extraction | Always | Never |
| 4 | RPM package matching | Always | Never |
| 5 | Red Hat VEX validation | Always | RPM NOT found in CoreOS (Step 4) |
| 6 | Final Report | Always | Never |

**Strict rules:**
1. Execute each step using the scripts and procedures below. After each step, print: `✓ Step N complete — [key finding]`
2. Every field in the final report must come from actual script outputs. Use `N/A — [reason]` for undetermined fields. Never fabricate values.
3. **FORBIDDEN COMMANDS — never use these, even inside loops or pipelines:**
   - `grep` — do not grep through JSON data files
   - `jq` — do not use jq filters on JSON data
   - `curl` — do not fetch URLs directly, use the helper scripts
   - `cosign` — do not call cosign directly, use `download_sbom.py`
   - `for ... do ... done` loops that process tool-result files
   - Any ad-hoc bash script, Python one-liner, or shell pipeline that parses or filters JSON data
4. **The ONLY allowed bash commands are:** running the helper scripts (`python $SCRIPTS_DIR/...`), `SCRIPTS_DIR=...` resolution, `test -f`, and `cat` to read a file.
5. **How to handle large VEX/SBOM data:** Read the raw JSON output directly in your context window. The data IS your input — analyze it in your reasoning, not with shell tools. If the output is too large, focus on the relevant sections (product_tree entries matching the CPE/component, vulnerabilities section) from what you can see. Do NOT attempt to filter it with grep/jq.
6. The `fetch_redhat_vex.py` script takes ONLY a CVE-ID argument — no flags. It returns the full raw VEX document.

---

### Step 1: Input Validation

```bash
python $SCRIPTS_DIR/validate_input.py --coreos --ocp-version [OCP_VERSION] --cve [CVE-ID]
```

If `valid` is false, print errors and stop.

Check the `input_type` field in the response:
- If `input_type` is `"rhsa"`: the user provided an RHSA advisory ID, not a CVE ID. Resolve it to individual CVEs first using the `fetch_rhsa_advisory.py` script (**do NOT use WebFetch or curl to access access.redhat.com**):
  ```bash
  python $SCRIPTS_DIR/fetch_rhsa_advisory.py [RHSA-ID]
  ```
  The script returns `cve_ids[]` — a list of CVE IDs covered by this advisory. Run Steps 2-6 for **each** CVE in the list against the same OCP version.

- If `input_type` is `"cve"`: proceed directly to Step 2 with the single CVE ID.

Print: `✓ Step 1 complete — input validated: [CVE-ID or RHSA-ID] against OCP [OCP_VERSION]`

---

### Step 2: CVE Reconnaissance

```bash
python $SCRIPTS_DIR/fetch_cve_metadata.py [CVE-ID]
```

From the output, identify the target package name, ecosystem, and vulnerable version ranges. For CoreOS, the primary ecosystem is `rpm`. If the CVE affects a Go module or Python package, check whether it's delivered via an RPM in CoreOS (the RPM name may differ from the upstream package name).

If `affected` is empty with errors indicating CVE not found: stop and report.

Print: `✓ Step 2 complete — [package name], ecosystem: [ecosystem]`

---

### Step 3: CoreOS Metadata Extraction

```bash
python $SCRIPTS_DIR/fetch_coreos_metadata.py [OCP_VERSION] --cache-dir /tmp/coreos-cache
```

**Caching:** The `--cache-dir` flag stores the result per OCP version. When validating multiple CVEs against the same OCP version, the CoreOS RPM list is fetched once and reused from cache for all subsequent CVEs. Always pass the same cache dir for all scans in a session.

This fetches OCP release info via `oc adm release info` (read-only query against public Red Hat release metadata — does not access the user's cluster) and runs `podman` to extract the RPM package list from the CoreOS image. It returns:
- `ocp_version`, `created`, `machine_os` (RHEL version), `rhel_version`, `rhel_major`
- `coreos_pullspec` — the exact CoreOS image digest
- `cpes` — `rhel` and `ocp` CPE strings for VEX matching
- `rpms[]` — all RPMs with `name`, `evr` (epoch:version-release), `arch`, `source` (rhel/ocp/fast_datapath)
- `rpm_count`, `rpm_by_source` — summary counts

Record the `cpes` for VEX matching in Step 5.

**Authentication failure handling:** If the script fails with an authentication error, it will return an error message indicating that a pull secret is required. In that case:
1. Report the error to the user and ask them to provide the path to their Red Hat pull secret file (downloadable from https://console.redhat.com/openshift/downloads).
2. Once the user provides the path, re-run the script with `--authfile`:
   ```bash
   python $SCRIPTS_DIR/fetch_coreos_metadata.py [OCP_VERSION] --cache-dir /tmp/coreos-cache --authfile [USER_PROVIDED_PATH]
   ```

Print: `✓ Step 3 complete — OCP [version], RHEL [rhel_version], [rpm_count] RPMs ([rhel] RHEL, [ocp] OCP, [fdp] Fast Datapath)`

---

### Step 4: RPM Package Matching

Search the `rpms[]` array from Step 3 for the affected package identified in Step 2.

**Matching rules:**
1. Match by RPM name (case-insensitive) against the CVE-affected package name
2. For Go/Python CVEs: the upstream package name (e.g., `golang.org/x/net`) won't match directly. Search for RPMs that could deliver the upstream package:
   - Go: search for RPMs containing `golang` or the module name component (e.g., `golang-x-net` for `golang.org/x/net`)
   - Python: search for `python3-<package>` or `python-<package>`
3. If found: record the installed `evr`, `source` (rhel/ocp/fast_datapath), and `arch`

**Version comparison:**
- Compare the installed RPM EVR against the vulnerable version range from Step 2 using RPM EVR ordering
- If installed version is within the vulnerable range: **vulnerable — version confirmed**
- If installed version is at or above the fixed version: **not vulnerable — patched version installed** — skip Step 5
- If comparison is inconclusive: **version comparison inconclusive** — proceed to Step 5

**If RPM NOT found:** record "Package not found in CoreOS RPM list" and skip to Step 6 (report as not applicable).

Print: `✓ Step 4 complete — RPM [found|not found], name: [rpm_name], version: [evr], source: [rhel|ocp|fast_datapath], verdict: [vulnerable|patched|inconclusive]`

---

### Step 5: Red Hat VEX Validation

Fetch the VEX summary for each CVE:
```bash
python $SCRIPTS_DIR/fetch_redhat_vex.py [CVE-ID]
```

The script returns a deduped summary with every product entry showing: `status`, `cpe`, `component` (base package name), and `remediations` (RHSA URLs). Read this output carefully.

**CRITICAL: The `cpe` field tells you EXACTLY which RHEL version the fix applies to. Do NOT confuse RHEL streams:**
- `cpe:/a:redhat:enterprise_linux:9::appstream` = RHEL 9.7 (latest, NOT EUS)
- `cpe:/a:redhat:rhel_eus:9.6::appstream` = RHEL 9.6 EUS
- `cpe:/a:redhat:rhel_eus:9.4::appstream` = RHEL 9.4 EUS
- `cpe:/a:redhat:openshift:4` = OCP 4 (all versions)
- `cpe:/o:redhat:enterprise_linux:8` = RHEL 8

**CoreOS uses RHEL EUS streams**, not the latest RHEL. From Step 3, `rhel_version` tells you which RHEL version CoreOS is based on (e.g., 9.6). Match against the EUS CPE for that version (e.g., `cpe:/a:redhat:rhel_eus:9.6`), NOT `cpe:/a:redhat:enterprise_linux:9`.

**Step 5a — Search for RHCOS/CoreOS entry under OCP CPE:**
In the VEX products list, look for entries where `component` contains `rhcos` or `coreos` AND `cpe` matches `cpe:/a:redhat:openshift:4` or the specific OCP version CPE. Record its status.

**Step 5b — Search for the RPM under the CORRECT CPE:**
In the VEX products list, find entries where `base_package` matches the RPM name from Step 4. Record entries for ALL CPEs, but mark which one matches the CoreOS RHEL version:

1. Check `cpe:/a:redhat:openshift:4` — this is the OCP product stream status
2. Check `cpe:/a:redhat:rhel_eus:[RHEL_VERSION]` — this is the RHEL EUS stream matching CoreOS
3. Check `cpe:/a:redhat:enterprise_linux:9` — this is the latest RHEL 9 (NOT the same as EUS)

For each match, record: `status`, `cpe`, and `remediations` (RHSA URL).

**Step 5c — Determine the assessment:**

| RHCOS entry | RPM under OCP CPE | RPM under RHEL EUS CPE | Assessment |
|---|---|---|---|
| Found (fixed) | — | — | CoreOS assessed and fixed |
| Found (known_affected) | — | Fixed | RPM patched in RHEL EUS but CoreOS not rebuilt |
| Missing | known_affected | Fixed | **VEX discrepancy** — RHCOS missing, RPM assessed |
| Missing | known_affected | Not found | known_affected under OCP, no EUS fix yet |
| Missing | Missing | Fixed | **VEX discrepancy** — RPM fixed in RHEL EUS but not tracked under OCP |
| Missing | Missing | Missing | **VEX data gap** |
| HTTP 404 | — | — | **No VEX coverage** |

**RHSA advisory matching (when input was RHSA):**
Compare the user-reported RHSA against the RHSA URLs in the VEX remediations:
- If the user's RHSA appears under the RHEL EUS CPE matching CoreOS: correct fix for this CoreOS
- If the user's RHSA appears under a DIFFERENT CPE (e.g., RHEL 9.7 instead of 9.6 EUS): wrong stream — report the correct RHSA from the matching EUS CPE
- If no RHSA exists under the matching EUS CPE: no fix available for this CoreOS's RHEL stream

Print: `✓ Step 5 complete — RHCOS VEX: [status|missing], RPM OCP: [status|missing], RPM RHEL EUS: [status|missing], severity: [severity]`

---

### Step 6: Final Report

```markdown
## CoreOS CVE Validation Report

- **CVE ID:** [CVE-ID]
- **OCP Version:** [OCP_VERSION]
- **CoreOS Image:** [coreos_pullspec]

- **Executive Summary:** [1-3 sentences: whether this OCP release's CoreOS is affected, VEX status, recommended action. For VEX gaps/discrepancies, include secalert@redhat.com recommendation. **When input was an RHSA:** state whether the reported RHSA is the correct fix for this CoreOS version, applies to a different version, or is not applicable.]

- **OCP Release Metadata:**
  - OCP Version: [version]
  - Release Date: [created]
  - Machine OS: [machine_os]
  - CoreOS Version Scheme: [rhel_based (OCP >= 4.19) | legacy (OCP < 4.19)]
  - CoreOS Build ID: [build_id — used for version comparison]
  - RHEL Base: [rhel_version]
  - Kubernetes Version: [kubernetes version]
  - CoreOS Image: [coreos_pullspec]

- **CVE Details:**
  - Package: [name]
  - Ecosystem: [ecosystem]
  - Vulnerable versions: [version ranges]
  - Sources: [MITRE, OSV, Go vuln DB]

- **CoreOS RPM Analysis:**
  - RPM found: [Yes | No — package not in CoreOS]
  - RPM name: [name]
  - Installed version: [evr]
  - RPM source: [RHEL repository | OCP repository (rhaos4) | Fast Datapath]
  - Version in vulnerable range: [Yes | No — patched | Inconclusive]
  - Total RPMs in CoreOS: [count] ([rhel] RHEL, [ocp] OCP, [fdp] Fast Datapath)

- **Red Hat VEX Status:**
  - RHCOS component status: [fixed | known_affected | known_not_affected | under_investigation | Not assessed — missing from VEX]
  - RHCOS CPE matched: [OCP CPE | N/A]
  - RPM package status: [status | Not assessed]
  - RPM CPE matched: [RHEL/OCP CPE | N/A]
  - Red Hat Severity: [Critical | Important | Moderate | Low | N/A]
  - RHSA Advisories: [URLs | N/A]
  - Not-affected justification: [flag label | N/A]

- **VEX Data Assessment:**
  - VEX discrepancy: [Yes — RHCOS entry missing but RPM assessed | No]
  - VEX data gap: [Yes — no VEX coverage | Yes — no RHCOS or RPM entry | No]
  - Action required: [Report to secalert@redhat.com | Monitor advisories | No action | N/A]

- **Reported Advisory Assessment:** [Include ONLY when the original input was an RHSA advisory ID]
  - Reported advisory: [RHSA-ID from user input]
  - Assessment: [Correct fix for this CoreOS version | Applies to different OCP/RHEL version — not applicable | Not applicable — CoreOS not affected | No patch available yet]
  - Correct advisory: [RHSA-ID if different | Same as reported | N/A]
```

## Dependencies

### Required MCP Servers
- None — this skill uses bundled Python scripts, not MCP tools

### Required Helper Scripts
- `validate_input` — validates CVE ID format and OCP version
- `fetch_cve_metadata` — queries MITRE, OSV.dev, and Go vuln DB
- `fetch_coreos_metadata` — extracts RPM list from RHCOS release image
- `fetch_redhat_vex` — retrieves Red Hat VEX security advisories
- `fetch_rhsa_advisory` — resolves RHSA advisory IDs to CVE lists

### Related Skills
- `container-cve-validator` — CVE validation for standard container images
- `cve-recon` — standalone CVE reconnaissance

### Reference Documentation
- [Red Hat CSAF VEX Data](https://security.access.redhat.com/data/csaf/v2/)
- [MITRE CVE API](https://cveawg.mitre.org/api/cve/)
- [OSV.dev API](https://api.osv.dev/v1/vulns/)