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 inside the skill's scripts/ subfolder:

SCRIPTS_DIR="scripts"
test -f "$SCRIPTS_DIR/validate_input.py" || { echo "Error: Scripts directory not found at $SCRIPTS_DIR"; exit 1; }

The scripts check internally for podman.

Workflow

MANDATORY EXECUTION CONTRACT:

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

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):

  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

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

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 reads the release image's image-references manifest via podman (read-only query against public Red Hat release metadata at quay.io — does not access the user's cluster) and then extracts 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:

   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:

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:

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

## 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
• MITRE CVE API
• OSV.dev API