rhoai-cve-analysis

RHOAI CVE Analysis

Analyze CVEs in a Red Hat OpenShift AI release to determine which vulnerabilities actually affect the product vs. inherited noise from base image layers.

Rules

• Always use the provided scripts for data processing. NEVER write ad-hoc Python, inline python3 -c commands, or custom code to analyze CVE data. The scripts handle all data loading, transformation, and output.
• Your role is to run the scripts and review their results — not to replicate or replace their logic.
• Do NOT directly read or edit data files — the scripts handle all data processing.
• Execute each step sequentially. Do NOT skip steps or collapse multiple steps into a single action.

Workflow

Follow these steps in order. The user will specify the RHOAI release version (e.g., v2.21, v2.23).

Output file naming: All output artifacts are namespaced by version to allow multiple analyses to coexist. Derive the version slug <VER> by stripping the v prefix from the release version (e.g., v2.25.2 → 2.25.2). Use <VER> in all output filenames throughout the pipeline.

Step 1: Collect CVE Manifest

Run the Pyxis query script to discover all container images and their CVEs:

uv run {{SKILL_DIR}}/scripts/fetch_rhoai_cves.py --release <VERSION> --output manifest-<VER>.json

If the user provides a specific release date, add --release-date YYYY-MM-DD. Otherwise the script derives it from the earliest image creation date.

This queries the Red Hat Pyxis container catalog API and produces a JSON manifest with all container images for the release and their associated CVE IDs.

Review the output: report the total number of images and unique CVEs to the user.

Step 2: Fetch CVE Details

Retrieve detailed vulnerability data from the Red Hat Security Data API:

uv run {{SKILL_DIR}}/scripts/fetch_cve_details.py --manifest manifest-<VER>.json --output cve_details-<VER>.json

This fetches severity, CVSS scores, Red Hat's impact statements, package fix states, and mitigation information for each CVE. Note: this may take several minutes for large CVE lists due to rate limiting.

Proceed directly to Step 2b. Do NOT write code to analyze cve_details-<VER>.json yourself — the pre-triage script handles all CVE analysis.

Step 2b: Fetch VEX Data

Fetch per-image vulnerability status from the Red Hat VEX/CSAF feed. This runs in parallel with Step 2 since both only need manifest-<VER>.json:

uv run {{SKILL_DIR}}/scripts/fetch_vex_data.py --manifest manifest-<VER>.json --output vex_data-<VER>.json

This provides per-container-image classification signals (known_affected, known_not_affected, fixed) which are more granular than the Security Data API's product-level data. It also provides CVE discovery/remediation dates for timeline analysis.

Step 3: Pre-Triage CVEs

You MUST run the following command to auto-classify CVEs. Do NOT attempt to analyze CVE data with your own code — the pre-triage script applies the full deterministic decision tree from the analysis methodology:

uv run {{SKILL_DIR}}/scripts/pre_triage.py --manifest manifest-<VER>.json --details cve_details-<VER>.json --vex vex_data-<VER>.json --output analysis-<VER>.json

The --vex argument is optional but recommended — it enables per-image VEX product status checks (highest priority in the decision tree) and adds temporal analysis fields.

This applies the decision tree checks (VEX product status, package_state, Red Hat statement, CVSS vector, base image package analysis) and auto-classifies obvious cases. Review the summary output — it reports how many CVEs were auto-classified vs. how many need your review.

Step 4: Review DEFERRED CVEs

Run the review script to apply additional heuristic rules to DEFERRED entries:

uv run {{SKILL_DIR}}/scripts/review_deferred.py --analysis analysis-<VER>.json --details cve_details-<VER>.json --vex vex_data-<VER>.json --manifest manifest-<VER>.json --output analysis-<VER>.json

The --vex argument is optional but recommended — it enables VEX-based reclassification of DEFERRED entries with known_affected status.

This script applies Tier 2 heuristic rules and Tier 3 conservative fallback rules. After this step, all CVEs will be classified — no manual review is needed. Review the summary output to verify counts are reasonable (expect 70-90% NOT_AFFECTED/MITIGATED for a typical release).

Step 5: Generate Remediation Plans

Run the remediation script to populate fix details for AFFECTED CVEs:

uv run {{SKILL_DIR}}/scripts/generate_remediation.py --analysis analysis-<VER>.json --details cve_details-<VER>.json --output analysis-<VER>.json

This generates standardized remediation text for each AFFECTED entry, including advisory references, fix package versions, affected image lists, and workaround suggestions when no fix is available.

Step 6: Generate Report

Generate the markdown report from the finalized analysis:

uv run {{SKILL_DIR}}/scripts/generate_report.py --manifest manifest-<VER>.json --analysis analysis-<VER>.json --output report-<VER>.md

The report format follows {{SKILL_DIR}}/references/REPORT_FORMAT.md.

Reference Documents

• Analysis methodology: {{SKILL_DIR}}/references/CVE_ANALYSIS_METHODOLOGY.md — Full decision tree for CVE impact analysis with RHOAI-specific context
• Report format: {{SKILL_DIR}}/references/REPORT_FORMAT.md — Report structure specification and analysis JSON schema
• Red Hat Security API: {{SKILL_DIR}}/references/RED_HAT_SECURITY_API.md — API endpoint reference (Security Data API + VEX/CSAF), response field descriptions, and rate limiting guidance

Tips

• Most CVEs in RHOAI images come from UBI base layers and are not affected. Expect 70-90% to be NOT_AFFECTED or MITIGATED for a typical release.
• Red Hat's statement field is the most valuable signal — it contains expert human analysis that is often definitive.
• The pipeline automatically handles uncertain cases — Tier 3 fallback rules ensure all CVEs are classified without manual intervention.
• Group related CVEs (same package, same root cause) to speed up analysis.
• For large CVE counts (>50), consider presenting the pre-triage results to the user in batches (e.g., by severity or image) for easier review. Always use the provided scripts — do not write custom analysis code for batching.