Triage Fixed Cves

triage-fixed-cves

Analyze an OpenShift release image to determine which Go standard library CVE Jira tickets have been addressed by the Go version used to build each component. Produces a per-CVE, per-component cross-reference report.

The user provides a release image pullspec (e.g. quay.io/openshift-release-dev/ocp-release:4.17.0-x86_64).

Execute every step below in order. Do not skip steps.

Step 1 — Extract component images from the release

oc adm release info <RELEASE_IMAGE> --output=json

Parse the JSON output to get the list of component image references. Each entry in .references.spec.tags[] provides a name (component name) and .from.name (image pullspec).

Each tag also carries .annotations metadata. Extract the io.openshift.build.source-location annotation — this is the canonical source GitHub repository URL for that component (e.g. https://github.com/openshift/cluster-version-operator). Also extract io.openshift.build.commit.id which gives the exact source commit SHA the image was built from. Record both for every component — they are used in Steps 2 and 4.

Auth failure: If oc adm release info fails due to an authentication error, STOP immediately. Report the auth failure to the user and do not proceed. Do not attempt to locate pull secrets, probe environment variables, or try alternative credential paths — the RWS pod's registry proxy handles authentication transparently, so an auth failure means the proxy does not have credentials for this registry and manual intervention is required.

Collect the full list of (component_name, image_pullspec, source_repo, source_commit) tuples before proceeding.

Step 2 — Identify the built binary per component via Dockerfile

For each component, identify exactly which binary is built and where it lands in the final image by looking up the component's Dockerfile. Do NOT scan the entire image for all ELF binaries.

CI images (most components)

Look up the ci-operator config at github.com/openshift/release/ci-operator/config/openshift/<repo>/. Match the correct config file for the release branch and build variant (e.g. openshift-cluster-version-operator-release-4.17.yaml). The config's images.items[] specifies the dockerfile_path for each image. Fetch that Dockerfile from the component's own repository at the exact source commit recorded in io.openshift.build.commit.id from Step 1 — do not use tree/main or the branch tip, as the release image may have been built from an older revision.

Builder substitutions: ci-operator configs may declare builder image overrides via images.items[].inputs.as — these replace FROM targets in the Dockerfile at build time, which can change the Go toolchain version used. Note any such substitutions when recording the component's build context.

Release / nightly images

Check the ocp-build-data config on the matching branch (e.g. github.com/openshift-eng/ocp-build-data/tree/openshift-4.17/images/<component>.yml). The from: and dockerfile: fields point to the Dockerfile.

OKD builds: The ocp-build-data image config may contain an okd_alignment section that specifies a different Dockerfile for OKD builds. These are typically named Dockerfile.scos or Dockerfile.okd. When this section is present, use the OKD-specific Dockerfile instead of the default one for OKD images. As with CI images, fetch the OKD Dockerfile at the exact source commit from io.openshift.build.commit.id (Step 1), not from the branch tip.

Parse the Dockerfile

Look for:

• go build -o <binary> or go install commands — these tell you the output binary name.
• COPY --from=builder <src> <dest> in multi-stage builds — this tells you where the binary is placed in the final image.

Example: a Dockerfile with go build -o /go/bin/cvo ./cmd/cvo and COPY --from=builder /go/bin/cvo /usr/bin/cluster-version-operator means the target binary is /usr/bin/cluster-version-operator.

Step 3 — Detect Go version per component

For each component, extract the Go version from the specific binary identified in Step 2.

podman pull <IMAGE>
podman create --name tmp-extract <IMAGE>
podman cp tmp-extract:<binary_path> /tmp/target-binary
podman rm -f tmp-extract   # always remove so the name is freed for the next component
go version /tmp/target-binary

Cleanup: Always run podman rm -f tmp-extract unconditionally after extraction (even on failure) so the container name is available for the next component. Wrap the extract-copy-remove sequence in a function or loop body to ensure cleanup is never skipped.

Parse the output. The format is:

/tmp/target-binary: go1.22.5

Extract the semver-style version (e.g. 1.22.5).

Important caveats

• Do NOT assume a single Go version across the release. Different components may use different Go toolchain versions. ci-operator builder image substitutions (images.items[].inputs.as) mean components can lag behind or jump ahead of the "default" Go version for a release.
• Inspect ONLY the specific binary identified from the Dockerfile. Do not scan the entire image filesystem for ELF binaries — that is slow, wasteful, and may pick up unrelated binaries from base images.
• If a component's Dockerfile cannot be found, or the component is not built from Go (e.g. a pure shell image or non-Go component), record it as N/A — no Go binary found and skip it in later steps.
• If the Dockerfile builds multiple Go binaries, checking any one of them is sufficient — all binaries in the same image share the same builder image and therefore the same Go toolchain version.
• Process components in batches to avoid excessive pull traffic. 10–20 at a time is reasonable.

Step 4 — Query Jira for open Go stdlib CVE trackers

Search for open Jira vulnerability issues that track Go standard library CVEs affecting the components in this release.

4a — Map release components to Jira components

Using the io.openshift.build.source-location source repo URLs extracted in Step 1, map each repo to its corresponding OCPBUGS Jira component name (e.g. openshift/cluster-version-operator → cluster-version-operator).

4b — Query for open stdlib CVE trackers

Using the discovered component list, query Jira with the coordinator's query_jira tool:

project = OCPBUGS
  AND type = Vulnerability
  AND labels in ("arc:stdlib")
  AND status not in (Closed, "Release Pending", Verified)
  AND component in (<discovered components>)
  AND summary ~ "openshift-<version>"
  ORDER BY component ASC

Replace <discovered components> with the comma-separated list of Jira component names from step 4a, and <version> with the target OCP version (e.g. 4.17).

For each returned issue, record:

• Jira issue key (e.g. OCPBUGS-12345)
• CVE ID (e.g. CVE-2024-24790) — extract the CVE-YYYY-NNNNN pattern from the issue summary
• Summary text
• Affected component(s) listed in Jira
• Fix version if mentioned in the issue

Step 5 — Exclude vendored dependency CVEs

Filter out CVEs that affect vendored Go dependencies rather than the Go standard library itself. The goal is to keep only CVEs that are fixed by upgrading the Go toolchain version.

Exclusion rules

1. golang.org/x/* packages: CVEs affecting golang.org/x/net, golang.org/x/crypto, golang.org/x/text, golang.org/x/image, etc. are vendored dependencies, not stdlib. Exclude them.

2. Hybrid CVEs: Some CVEs affect both stdlib packages AND vendored modules (e.g. a CVE that affects net/http in stdlib but also golang.org/x/net/http2). Classify these into a separate "Hybrid" category — do not list them as both included and excluded:

   • The stdlib portion IS fixed by a Go version upgrade — include this in the per-CVE cross-reference (Steps 6–7).
   • The vendored portion requires a separate dependency bump — note this in the hybrid section of the report.

3. Detection method: Read the Jira issue description and any linked advisories. Look for:

   • Package paths starting with golang.org/x/ — vendored
   • Package paths like net/http, crypto/tls, os, runtime — stdlib
   • References to the Go vulnerability database entry

Produce three lists from this step:

• Stdlib-only CVEs → proceed to Steps 6–7 cross-reference
• Hybrid CVEs → proceed to Steps 6–7 cross-reference (stdlib portion) AND note in the dedicated hybrid section of the report (Step 7.4)
• Vendored-only CVEs → excluded; listed in the report (Step 7.5)