Query Open Cves

When to Use

Use this skill when Phase 1 of the node-cve:triage command needs to fetch all open CVE trackers from Jira and deduplicate them into a list of unique CVEs.

Prerequisites

• jira CLI configured with valid credentials
• Environment variables: JIRA_API_TOKEN
• Network access to Jira instance

Implementation Steps

Step 1: Load Node team components

Read the CVE-tracked component list from the node-team shared components reference. Use the full "Jira Components (OCPBUGS)" list plus the additional CVE triage components (Driver Toolkit, Machine Config Operator).

Default behavior (no --component flag): include ALL Node team components, and ONLY Node team components. "No flag" does not mean "no filter" — it means "the full Node component list." Never construct a query that omits the component filter entirely, even when no --component value was given.

If --component was specified, use only that single component instead of the full list. The value must match an entry in the shared reference exactly; if it does not, print an error listing the valid component names and exit rather than silently falling back to an unfiltered query.

The Jira saved filter "Node Components" (ID 91645) does not include Driver Toolkit and Machine Config Operator, so the explicit list from the shared reference is used for CVE queries to ensure completeness.

CRITICAL SAFEGUARD: This component filter is what scopes every downstream step (analysis, reporting, and — critically — Jira comment posting in Phase 3) to Node team trackers only. Many CVEs (especially Go stdlib or vendored-dependency vulnerabilities) have 50-200+ tracker issues across dozens of OpenShift teams. Omitting or bypassing this filter — for example by later re-querying Jira with only a CVE ID and no component constraint — is what caused the 2026-07-15 incident where Node-specific analysis was posted to ~200 non-Node trackers (HyperShift, Storage, Networking, Installer, etc.). See the report-findings "Node Team Component Safeguard" section for the posting-time re-validation this feeds into.

Step 2: Query Jira

Build and execute the JQL query. The component in (...) clause is mandatory in every invocation of this query, whether or not --component was passed:

jira issue list -q "project = OCPBUGS AND type = Vulnerability AND component in (<components from shared reference, or the single --component value>) AND status not in (Closed, Done, Verified)" --plain --no-headers --columns KEY,SUMMARY,COMPONENT,STATUS,ASSIGNEE,LABELS

If --days N was specified, add AND updated >= -${N}d to the JQL.

Handle pagination: the jira CLI returns up to 100 results by default (format: --paginate <from>:<limit>). If the result count equals 100, paginate by re-running with --paginate 100:100, --paginate 200:100, etc. until fewer than 100 results are returned.

Sanity check: After fetching results, verify that every returned COMPONENT value is actually in the Node team component list (or, when --component was given, equals that value). If any row has an unexpected component, this indicates a JQL construction bug — log a warning with the offending tracker key and component, and exclude that row rather than propagating it downstream.

Step 3: Parse results

For each row in the output:

1. Extract the issue key (e.g., OCPBUGS-85948)
2. Extract the CVE ID from the summary using regex: CVE-[0-9]{4}-[0-9]+
3. Extract the OCP version from the summary brackets: \[openshift-([^\]]+)\]
4. Extract component name
5. Extract status and assignee
6. Extract labels (preserve pscomponent:* labels for Phase 2 repo mapping)

Step 4: Deduplicate by CVE ID

Group all tracker issues by CVE ID. For each unique CVE, build a record:

{
  "cve_id": "CVE-2026-32281",
  "summary": "Go crypto/x509: Denial of Service via inefficient certificate chain validation",
  "components": ["Node / CRI-O"],
  "status": "New",
  "assignee": "ocp-sustaining-blocked-trackers",
  "tracker_keys": ["OCPBUGS-85948", "OCPBUGS-85932", "OCPBUGS-85914", "..."],
  "affected_versions": ["4.12.z", "4.13.z", "4.14.z", "4.15.z", "4.16.z", "4.17", "4.18", "4.19"],
  "labels": ["pscomponent:cri-o", "SecurityTracking"]
}

A single CVE may span multiple components (e.g., both "Node / CRI-O" and "Machine Config Operator"), so components is an array collecting all distinct component values across tracker issues for that CVE.

Use the highest version tracker for the "primary" assignee and status (issues on newer versions are typically more actively managed).

Step 5: Filter to latest OCP version

Auto-detect the latest OCP version from the query results and filter to it. This prevents the Node team from triaging versions owned by the sustaining team.

1. If Step 2 returned zero Jira rows, skip version filtering — there are no trackers to filter. Return an empty CVE list with version_filter: null. Print: "No open CVEs found; version auto-detection skipped."
2. Collect all OCP versions extracted from tracker summaries in Step 3 (e.g., 4.12.z, 4.14.z, 4.17, 4.18, 4.19, 5.0).
3. Discard non-numeric versions: Any version string that cannot be parsed as a numeric major.minor pair (e.g., latest, nightly, or other non-version labels) must be discarded with a warning — do not treat it as a valid OCP version. Only versions matching the pattern <digits>.<digits> (optionally followed by .z) are valid. If ALL extracted versions are discarded (no valid numeric versions remain), treat this the same as zero Jira rows: return an empty CVE list with version_filter: null. Print: "No valid numeric OCP versions found in tracker summaries; version auto-detection failed."
4. Determine the latest version by sorting the remaining valid versions numerically:
   • Strip trailing .z suffixes for comparison purposes (.z indicates a z-stream release, which is always an older maintenance stream).
   • Parse each version as (major, minor) — e.g., 5.0 → (5, 0), 4.19 → (4, 19), 4.12.z → (4, 12).
   • Sort descending by major, then by minor. The first entry is the latest version.
   • version_filter always stores the stripped major.minor form (no .z suffix), since .z is a release-stream qualifier, not a distinct version. Example: given [4.12.z, 4.14.z, 4.17, 4.18, 4.19, 5.0], the latest is 5.0 and version_filter is "5.0".
5. For each CVE record from Step 4, filter trackers to the latest version. Compare each tracker's OCP version against version_filter after stripping any .z suffix from the tracker version (so 4.14.z matches filter 4.14):
   • Remove non-matching entries from tracker_keys, affected_versions, components, and labels — keep only values associated with retained trackers.
   • If a CVE has no remaining trackers after filtering, exclude it entirely — it has no tracker for the latest version and is therefore a sustaining-team concern only.
6. After filtering, rebuild each CVE record's metadata entirely from the retained tracker set. Per-tracker associations (component, labels, assignee, status) must be preserved during Step 4 deduplication so they can be used here. Recompute: tracker_keys, affected_versions, components, labels, assignee, status, and is_unassigned. This ensures no stale metadata from removed trackers leaks into Phase 2 (repo selection) or Phase 3 (reporting).
7. Print: "Version filter: (auto-detected). Older versions are triaged by the sustaining team."

Step 6: Identify unassigned CVEs

Flag CVEs where:

• Assignee is a bot account (e.g., "ocp-sustaining-blocked-trackers") or empty
• Status is "New" (not yet picked up)

Return Value

{
  "skill": "query-open-cves",
  "status": "success",
  "version_filter": "5.0",
  "total_trackers": 8,
  "total_trackers_before_version_filter": 45,
  "unique_cves": 6,
  "cves": [
    {
      "cve_id": "CVE-2026-32281",
      "summary": "...",
      "components": ["Node / CRI-O"],
      "status": "New",
      "assignee": "ocp-sustaining-blocked-trackers",
      "is_unassigned": true,
      "tracker_keys": ["OCPBUGS-85948"],
      "affected_versions": ["5.0"],
      "labels": ["pscomponent:cri-o"]
    }
  ]
}

version_filter is the auto-detected latest OCP version in stripped major.minor form (e.g., "5.0"). It is null when no version could be detected (zero Jira rows or all extracted versions were non-numeric) — in that case cves is an empty array. Downstream consumers must check for null before using version_filter as a version string.

Error Handling

• If jira CLI returns an error, print the error and exit. Common causes: expired API token, network issues, invalid JQL.
• If the query returns 0 results, return an empty list (not an error).
• If a CVE ID cannot be extracted from a summary, log a warning and skip that tracker.