Address image CVE burden: float bases, trim runtime, unify Go toolchain

[anthonytwh]

Acts on P1–P3 of the remediation plan added in the first commit. Driven by the ISS v2.12.7 scan (forklift-latest/v2.12.7/results_image_all_2026-08-28::21:29:57:055): 13,548 unique findings, 3,043 crit/high across 8 images.

Full analysis and the reasoning behind each change is in docs/security/cve-remediation-plan.md. Review that first — the code changes are mechanical once the causes are clear.

What the scan actually says

74% of the entire finding count (9,963 of 13,548) is the libguestfs supermin appliance kernel inside forklift-virt-v2v, reported by grype only, matched against upstream kernel.org ranges instead of RHEL errata. That block is deliberately not addressed here — grype inflates every ISS report, so it is being handled as a scanner-level review rather than per-product suppression. Written up separately in image-scan-service.

Strip it out and the addressable set is 3,585 findings / 689 crit/high, of which 473 have a published fix.

Changes

P1 — base images can move again

35 of 40 Containerfiles ran no package update, so the pinned base digest was the permanent patch level. Pins were 3.5–12 months stale.

Every UBI base in the repo is now :latest — upstream and downstream, registry.access.redhat.com and registry.redhat.io. No timestamp pin remains. Each :latest tag was verified to resolve before being adopted:

ubi9-minimal, ubi9/ubi-minimal, ubi8-minimal, ubi8/ubi, ubi9, ubi10, ubi10/ubi-minimal, ubi9/nginx-126.

go-toolset stays on :1.26, deliberately. That tag already floats across Red Hat rebuilds, so it picks up every toolchain refresh; :latest would additionally float the Go minor, which breaks the single-toolchain goal and re-risks the GODEBUG behaviour change described under P3.

Trade-off, flagged for reviewers: builds are no longer bit-reproducible from the Containerfile alone. This is the right default for a security-driven rebuild with no bot moving digests, but it is a deliberate choice, not an oversight.

P2 — runtime trim, scoped by measurement

--setopt=install_weak_deps is applied only where it measurably changes the image. It was initially added everywhere; that was wrong, and the no-op sites were removed in d6bbe183a. Measured with --assumeno:

Image	With weak deps	Without	Verdict
virt-v2v (CentOS Stream)	324 pkgs / 2.2 GB	297 pkgs / 1.4 GB	keep
deep-inspection (CentOS Stream) †	408 pkgs / 1.1 GB dl	330 pkgs / 223 MB dl	keep
ovirt-populator	8 pkgs	8 pkgs	no-op, removed
ubi9-minimal + tar (×10)	tar only	tar only	no-op, removed

† deep-inspection is not in TIGERA_IMAGES, so this fork neither builds nor pushes it, and it was in neither scan. The measurement is real and is why the flag stays in that file, but it is not an improvement this fork can claim.

tar on ubi9-minimal pulls in exactly one package — itself. The flag was pure noise on every ubi-minimal image; microdnf -y update alone is what gets current Red Hat libraries there.

Where the flag is kept, two former weak dependencies are installed explicitly, because dropping them would be a functional regression rather than a size win:

• passt and libvirt-daemon-config-network. libguestfs only recommends them, and the image runs LIBGUESTFS_BACKEND=libvirt:qemu:///session, which breaks without them. This is the one place the trim could have caused a regression.
• The nbdkit metapackage drops, and that is safe. virt-v2v hard-requires every plugin it uses (nbdkit-server, -basic-filters, -basic-plugins, -curl-plugin, -nbd-plugin, -python-plugin, -ssh-plugin, -vddk-plugin); all retained. The metapackage was only a recommendation of libvirt-daemon-driver-qemu.

Package updates were added to every shipped stage that lacked one — including the virt-v2v appliance stages, whose blob is copied into the final image and where upstream had drifted from downstream. Builder stages deliberately get none: only the compiled binary leaves them, and golang is already current at 1.26.7-1.el9_8 via the floating tag, so an update there cannot change a shipped image's findings.

Note: microdnf rejects install_weak_deps=False and requires =0; dnf and yum accept both. All 23 sites use =0 so the two cannot be confused.

P3 — one Go toolchain

Shipped images spanned Go 1.22.5, 1.24.6, 1.25.9 and 1.26.3. All 32 builder stages now use go-toolset:1.26, so every shipped binary carries the 1.26 stdlib.

Module	Package	Was	Now
main	golang.org/x/crypto	v0.50.0	v0.55.0
main	golang.org/x/net	v0.53.0	v0.58.0
main	golang.org/x/oauth2	v0.23.0	v0.36.0
validation	golang.org/x/crypto	v0.40.0	v0.55.0
validation	golang.org/x/net	v0.42.0	v0.58.0
validation	containerd/v2	v2.1.4	v2.3.4
vsphere-copy-offload	golang.org/x/crypto	v0.50.0	v0.55.0

x/oauth2 was CVE-2025-22868 (HIGH) and was the only finding trivy reported against the rebuilt virt-v2v image; it now scans clean on that axis.

go directives are not uniform, on purpose. The root module is go 1.25.0 and .konflux/validation is go 1.26.3 (which containerd/v2 v2.3.4 requires). Setting the root to 1.26 looked tidier and actively broke things: cmd/vsphere-copy-offload-populator carries replace github.com/kubev2v/forklift => ../../, so the root directive raised that submodule to 1.26, and the directive selects GODEBUG defaults — Go 1.26's stricter net/url host:port parsing then failed nine internal/vantara tests that pass on main. The directive is a floor, not the build version, so 1.25.0 at the root still yields a 1.26 stdlib. Reverted in d6bbe183a.

That same commit fixes a related break: raising the root's dependencies raises the submodule's effective requirements through that replace, and its Containerfile runs go mod download before make build, which rewrites its go.mod and leaves vendor/ stale. Resynced.

build/validation/Containerfile rewritten. It previously did:

RUN curl -L https://github.com/open-policy-agent/opa/releases/download/v1.8.0/opa_linux_${TARGETARCH}_static > /usr/bin/opa

An unverified network fetch with no checksum, which also pinned the validation image to whatever Go the OPA project released with — 1.22.5, the oldest toolchain in the product. It now builds OPA from source with the repo's own toolchain, matching what Containerfile-downstream already did. OPA itself stays at v1.8.0; upgrading it changes validation behaviour and belongs in its own PR.

forklift-operator — the one image that was getting worse

forklift-operator was the only image whose crit/high went up between scans, and the only one carrying stale curl (7.76.1-40.el9 against 7.76.1-40.el9_8.5 everywhere else). All four actionable curl CVEs in the scan were on it alone.

Its update step was commented out. Worth recording why uncommenting it as written fails: the base ships microdnf, not dnf, so the line errored with exit 127. Switched to microdnf, verified by querying the rpmdb in the built image:

before   curl-minimal-7.76.1-40.el9
after    curl-minimal-7.76.1-40.el9_8.5

Confirmed in the follow-up scan: CVE-2026-8286, -9547, -1965 and -3783 all went PRESENT → GONE.

Build and push targets

build-all-images-tigera and push-all-images-tigera build/push the set to gcr.io/unique-caldron-775/tigera-forklift, and push-all-images-quay to quay.io/tigeradev, so the images can be scanned outside the upstream quay.io/kubev2v namespace. They set REGISTRY/REGISTRY_ORG as target-specific variables, which propagate to the existing prerequisite targets, so no target definitions are duplicated. build-all-images and push-all-images are unchanged.

Both derive from one TIGERA_IMAGES list of 15, excluding the operator index: that build runs opm render <bundle> inside the build container, which pulls the bundle from the registry with no credentials available to it. Pushing the bundle first does not help — verified it was pushed before the index build ran and the pull still 403'd, because the GCR repo is private and the in-container pull is anonymous. Upstream avoids this only because quay.io/kubev2v is public. The index holds opm plus catalog YAML, so there is nothing in it to scan.

The unused virt-v2v fedora variant is commented out rather than deleted: no Makefile target referenced it and it appeared in no scan, while still needing a Fedora major bump to stay supported.

Verification

• docker build of forklift-controller, forklift-api, validation, cli-download, ova-provider-server, populator-controller, vsphere-copy-offload-populator, forklift-operator, virt-v2v (Containerfile-upstream) and ovirt-populator (Containerfile-upstream) — all pass
• Full make build-all-images-tigera: 15/15, zero errors. All 15 pushed and each manifest verified pullable from GCR and Quay
• Shipped opa binary reads go1.26.7 (Red Hat 1.26.7-1.el9_8) X:strictfipsruntime, linking containerd/v2 v2.3.4, x/crypto v0.55.0, x/net v0.58.0
• cmd/vsphere-copy-offload-populator test suite: 10/10 packages pass
• Trim verified in the built image: webkit2gtk3-jsc, libproxy-webkitgtk4, linux-firmware, nfs-utils, rpcbind, vim-enhanced gone; virt-v2v, passt, libvirt-daemon-config-network and every nbdkit-* plugin present
• Weak-dependency deltas, microdnf/yum --setopt syntax, and every :latest tag's existence all checked in real containers rather than assumed

Not verified locally:

• Konflux hermetic -downstream builds need rpms.lock.yaml regeneration with entitled repos
• Containerfile-downstream-fssupport needs Red Hat internal Brew access
• The ubi9 virt-v2v / ubi8 ovirt-populator variants need a Red Hat subscription; virt-v2v is not in the UBI repos at all, which is why the CentOS Stream Containerfile-upstream variants exist and are what our targets build

Which files this fork actually builds

38 Containerfiles change here. 14 of them are built by this fork. The
build-all-images-tigera / push-all-images-tigera / push-all-images-quay rules fan out
over TIGERA_IMAGES, and each passes -f build/<name>/Containerfile or
Containerfile-upstream*. downstream appears nowhere in the Makefile's image rules.

The other 24 are edited deliberately, for consistency with upstream rather than for effect
here — 17 Containerfile-downstream files (consumed only by the .tekton PipelineRuns,
and Konflux does not run on this fork), the three entitlement-gated variants where the fork
builds the -upstream flavour instead, deep-inspection/* (not in TIGERA_IMAGES), and the
fedora variant this branch comments out entirely.

Letting the two lineages diverge would make every future rebase against upstream harder and
leave a reader unable to tell which file is authoritative. The trade-off is a diff larger
than the effective change, so: nothing in the 24 should be read as an image this fork
hardened.

Consequence for the numbers: no CVE figure in this PR or in
docs/security/cve-remediation-plan.md is credited to a -downstream, deep-inspection or
entitlement-gated image. Every results table covers images in TIGERA_IMAGES, which is also
exactly the set that was scanned.

Deliberately out of scope

• P0 (appliance kernel) — scanner-level review, tracked in image-scan-service. 5.14.0-741.el9 is already the newest CentOS Stream 9 build, so this is a matching problem, not patch lag
• Kernel NEVRA unpinning in .konflux/virt-v2v/runtime/rpms.in.yaml — not done. It only affects the hermetic Konflux build, which runs in Red Hat's tenant and cannot be exercised or verified here. Reverted in 56aaad8d8 along with the other Konflux and CI-workflow changes, which are dormant in this fork
• P4 — must-gather and console-plugin are consumed prebuilt from quay.io/kubev2v with no Containerfile here. must-gather is the largest remaining actionable block at 299 crit/high, 106 of them webkit2gtk3. Pending a decision on whether it is used in the L2 migration flow
• P5 — iss-cli build gate, documented but not wired; needs the Tigera pipeline to exist

Spotted, not changed

build/virt-v2v/Containerfile-downstream and Containerfile-downstream-fssupport install RPMs with --setopt=sslverify=false. Limited exposure in a hermetic build, but a bad default to carry. Left alone because verifying the change needs a hermetic build.

--setopt=install_weak_deps on Containerfile-downstream-fssupport was reverted: that transaction previously ran with weak deps on, so disabling them dropped passt, and UBI10 will not run under emulation here to validate a forward fix.

Measured effect

Like-for-like on the six images present in both the 08-28 and 09-03 scans:

Image	Crit/High before	After
forklift-controller	55	12
forklift-validation	78	17
populator-controller	42	12
forklift-operator	33	31
ovirt-populator	33	29
forklift-virt-v2v	2,426	2,396

The Go-service images dropped 71–78%. virt-v2v is flat because 94% of its findings are the deferred appliance-kernel block.

Read per-image numbers, not the total: the later scan covers 15 images rather than 8, and virt-v2v-xfs alone contributes another 10,694 findings identical to virt-v2v. The residual is dominated by three classes no rebuild can move — the appliance kernel (~10k, grype/NVD mismatch), 338 curl entries marked "No fix available", and 53 twistcli findings (31 HIGH) where a Red Hat Satellite advisory's CVE list is cross-joined onto libcomps.

[Copilot]

🟡 Changes recommended

Downstream virt-v2v runtime images disable weak deps but don’t explicitly install passt and libvirt-daemon-config-network despite using LIBGUESTFS_BACKEND=libvirt:qemu:///session, which can cause runtime breakage.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR implements the P1–P3 CVE remediation steps by (1) allowing base images to float (with explicit update steps), (2) trimming runtime dependencies by disabling weak deps and explicitly installing required packages, and (3) unifying the repository on a single Go toolchain (go-toolset 1.26) with updated vendored dependencies. It also removes an unverified OPA binary download in the validation image by building OPA from source using the repo’s Go toolchain.

Changes:

• Switch multiple Containerfiles from pinned UBI/nginx digests to :latest and add/update package update+cleanup steps; normalize weak-deps handling (install_weak_deps=0).
• Unify Go toolchain usage to go-toolset:1.26 and update Go module/vendored dependencies accordingly.
• Rework validation image build to compile OPA from source rather than downloading a prebuilt binary.

File summaries

File	Description
go.mod	Bumps module go directive to 1.26.0 and updates golang.org/x/* versions.
vendor/modules.txt	Reflects updated vendored module versions (x/crypto, x/net, x/tools, etc.).
vendor/golang.org/x/tools/**	Updates x/tools internals for newer Go/export formats and iter APIs.
vendor/golang.org/x/net/**	Updates http2/idna/html logic and adds go1.27 transition build tags.
vendor/golang.org/x/crypto/**	Security/robustness updates across ssh/pbkdf2/poly1305/cryptobyte.
vendor/golang.org/x/sys/**	Regenerated syscall/types/constants across OS/arch targets.
build/validation/Containerfile	Replaces unverified curl download of opa with a source build using repo toolchain; updates base to ubi9-minimal:latest and adds microdnf update.
build/validation/Containerfile-downstream	Moves builder to go-toolset:1.26.
build/virt-v2v/Containerfile	Floats base images to ubi9:latest, disables weak deps, adds explicit passt and libvirt-daemon-config-network, and installs catatonit in the main install transaction.
build/virt-v2v/Containerfile-upstream	Adds dnf update, disables weak deps, and explicitly installs passt + libvirt-daemon-config-network.
build/virt-v2v/Containerfile-upstream-xfs	Same runtime-trim pattern plus explicit dependencies.
build/virt-v2v/Containerfile-upstream-fedora	Same runtime-trim pattern plus explicit dependencies.
build/virt-v2v/Containerfile-downstream	Updates to go-toolset:1.26 and normalizes weak deps setting (but currently missing explicit passt/network packages in runtime install).
build/virt-v2v/Containerfile-downstream-fssupport	Adds install_weak_deps=0 to hermetic installs (but currently missing explicit passt/network packages in pinned RPM set).
build/virt-v2v-rhel9/Containerfile	Floats base images to ubi9:latest, disables weak deps, adds explicit passt and libvirt-daemon-config-network, and installs catatonit in the main install transaction.
build/virt-v2v-rhel9/Containerfile-downstream	Updates to go-toolset:1.26 and normalizes weak deps setting (but currently missing explicit passt/network packages in runtime install).
.konflux/virt-v2v/runtime/rpms.in.yaml	Removes kernel NEVRA pins so lockfile refresh can advance the appliance kernel.
.konflux/forklift-operator-bundle/go.mod	Unifies Konflux operator-bundle go directive to 1.26.0.
build/forklift-api/Containerfile	Floats runtime base to ubi9-minimal:latest, adds microdnf update, and moves builder to go-toolset:1.26.
build/forklift-controller/Containerfile	Same toolchain/base update pattern as other Go-built images.
build/populator-controller/Containerfile	Same toolchain/base update pattern; normalizes weak deps disabling for tar install.
build/ova-provider-server/Containerfile	Same toolchain/base update pattern; normalizes weak deps disabling for tar install.
build/ova-proxy/Containerfile	Same toolchain/base update pattern; floats base to ubi9-minimal:latest.
build/openstack-populator/Containerfile	Same toolchain/base update pattern; adds microdnf update.
build/hyperv-provider-server/Containerfile	Same toolchain/base update pattern; adds microdnf update.
build/ovirt-populator/Containerfile	Floats ubi8/ubi base to :latest, adds dnf update, and moves builder to go-toolset:1.26.
build/ovirt-populator/Containerfile-upstream	Adds dnf update, disables weak deps, and moves builder to go-toolset:1.26.
build/forklift-cli-download/Containerfile	Moves builder to go-toolset:1.26 and floats nginx base to ubi9/nginx-126:latest.
build/vsphere-copy-offload-populator/Containerfile	Moves builder to go-toolset:1.26 and floats runtime base to ubi9-minimal:latest with microdnf update.
build/forklift-operator-index/Containerfile	Floats builder base to ubi9-minimal:latest, adds microdnf update, disables weak deps for gettext.
build/deep-inspection/Containerfile	Moves builder to go-toolset:1.26, adds dnf update, disables weak deps in install step.
build/deep-inspection-rhel9/Containerfile	Moves builder to go-toolset:1.26, adds dnf update, disables weak deps in install step.

Review details

• Files reviewed: 41/238 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

CI/toolchain configuration is inconsistent (outdated actions/setup-go@v4 in key workflows and a Go 1.25 version file used for vendoring while builders moved to Go 1.26), which risks breaking builds and contradicts the PR’s “unified toolchain” intent.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

build/forklift-controller/Containerfile-downstream:1

• This downstream Containerfile changed from a build-specific go-toolset tag to the floating :1.26 tag. The PR description notes that -downstream images should remain pinned (Konflux/Mintmaker-managed) to preserve reproducibility; using a floating tag here makes the downstream build non-deterministic and may diverge from that plan.

Recommend pinning this base (e.g., to a specific go-toolset build tag or digest) consistently across downstream Containerfiles.

• Files reviewed: 44/251 changed files
• Comments generated: 3
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

CI now selects Go from cmd/vsphere-copy-offload-populator/go.mod (Go 1.25) for one job, undermining the stated “single Go toolchain” objective and risking inconsistent CI outcomes.

Review details

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

build/validation/Containerfile:14

• The OPA build step doesn’t use BuildKit cache mounts, unlike the other Go build stages in this repo. This will force a full module/build cache download/compile on every image build, increasing CI time and load on module infrastructure.

.github/workflows/golangci-lint.yaml:68

• The offload vendor verification job now derives the Go version from cmd/vsphere-copy-offload-populator/go.mod, which currently declares go 1.25.0. This reintroduces multiple Go toolchains in CI (main jobs use the root go.mod at Go 1.26) and can cause inconsistent build/lint behavior versus the Containerfiles that now use go-toolset:1.26.

      - uses: actions/setup-go@v6
        with:
          go-version-file: cmd/vsphere-copy-offload-populator/go.mod
          cache: false

• Files reviewed: 47/254 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The change set combines broad base-image floating, runtime package update behavior changes, and large vendored dependency updates, which warrants human verification of build and runtime impacts across the affected images.

Review details

• Files reviewed: 40/247 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Multiple Containerfiles use microdnf install --setopt=install_weak_deps=0 ..., but --setopt must be passed before the subcommand in microdnf, otherwise image builds will fail.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 40/247 changed files
• Comments generated: 16
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The vendored ForEachElement change can incorrectly skip method traversal due to an overly broad TypeParams() != nil check, which risks breaking x/tools behavior at runtime/build time.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 43/459 changed files
• Comments generated: 0 new
• Review effort level: Lite

[anthonytwh]

Latest scan: https://iss.tigera.org/results?path=tigera-forklift%2Fcve-ep3-2%2Fresults_image_all_2026-09-03%3A%3A18%3A00%3A17%3A937%2Fresults%2Fraw_results.csv

[Copilot]

🔵 Needs a closer look

Several downstream images now float to :latest without consistently running package updates, and there are stated PR goals (pinned downstream bases / unified go directives) that currently conflict with what’s in the diff.

Review details

Suppressed comments (5)

Previously missed (2) — in code that hasn't changed since the last review.

build/ova-proxy/Containerfile-downstream:14

• This runtime stage also switched to a floating base (ubi9-minimal:latest) but has no microdnf update step. Add an update+clean layer so rebuilt images actually pick up fixed RPMs even if the base tag lags behind.
  build/validation/Containerfile:5
• PR description states that module go directives are unified as part of the Go toolchain consolidation, but the repo root still declares go 1.25.0 (see go.mod:3) while images and vendored deps have moved forward. If the project intends to require Go 1.26, the go directives should be bumped in the root module (and any shipping submodules) to match the toolchain policy.

build/forklift-controller/Containerfile-downstream:15

• The runtime stage switched to a floating base (ubi9-minimal:latest), but it still doesn't run microdnf update. Depending on when the base image was published, this can leave known-fixed CVEs in the shipped image. Run microdnf -y update before installing tar (and keep clean all).
  build/vsphere-copy-offload-populator/Containerfile-downstream:15
• PR description says the registry.redhat.io bases in *-downstream Containerfiles are left pinned (Konflux/Mintmaker-managed), but this file now floats ubi9-minimal:latest. Please either re-pin this base (if downstream should stay Mintmaker-managed) or update the PR description/plan so expectations match what the downstream build will do.
  build/ova-provider-server/Containerfile-downstream:14
• This downstream runtime stage uses ubi9-minimal:latest but still skips microdnf update, which can leave fixed CVEs present depending on base publish timing. Consider applying the same update-before-install pattern across other *-downstream images with ubi*-minimal:latest (e.g. populator-controller, hyperv-provider-server).

• Files reviewed: 43/459 changed files
• Comments generated: 0 new
• Review effort level: Lite

[aaaaaaaalex]

Reviewed against the release tree. The load-bearing claims hold up: passt and libvirt-daemon-config-network are explicitly installed on both virt-v2v variants we ship, so the weak-deps trim can't break guest conversion; OPA is now pinned and checksum-verified through go.mod/go.sum instead of an unverified curl; both microdnf sites use =0, so the one tool that rejects =False never sees it. The fedora-variant disable is documented rather than deleted, and the new image targets' reason for excluding the operator index matches behavior we've hit ourselves.

Two things to fix before merge, one of them in the branch history:

An 81 MB compiled binary is committed: cmd/kubectl-mtv/kubectl-mtv (mode 755). It has to come out by rewriting the branch — a follow-up deletion commit still leaves 81 MB in history forever — and a .gitignore entry should keep it from coming back. (Filed in the body because a review comment can't anchor to a binary file.)

The description has drifted from the branch. It still describes the kernel-NEVRA unpinning in rpms.in.yaml and the CI workflow bumps, both reverted in 56aaad8 (the comment threads say so; the body doesn't), and the "all 40 sites normalised to =0" claim doesn't match the branch (see inline comment). Worth updating since the body becomes the merge commit's story.

🤖 Generated with Claude Code

[aaaaaaaalex]

The description says all install sites were normalised to install_weak_deps=0, but the branch has 21 sites of which 13 dnf sites (this one included) still say =False. Nothing is broken — dnf accepts both spellings and the two microdnf sites are already =0 — but the normalisation this claim promises didn't land. Suggest finishing it (13 one-character-class edits) or dropping the claim from the description.

[aaaaaaaalex]

Two things on the must-gather paragraph.

Wording: suggest "whether must-gather is used in the L2 migration flow" — the sentence doesn't need to name a product.

On the pending decision itself: suggest deciding in favour of building must-gather in this fork rather than consuming it prebuilt. kubev2v/forklift-must-gather is Apache-2.0 with its own Containerfile, so nothing blocks it, and the mirror path has already bitten us once — the digest our first release mirrored turned out to be two years stale. Building it here also puts the largest remaining actionable block (299 crit/high in the scan) under the same floating-base and weak-deps regime as every other image in this PR.

[aaaaaaaalex]

The gs://iss-upload/... bucket path adds nothing for readers of this repo — the scan identifier on the line above already names the dataset. Suggest dropping the path.

[Copilot]

🔵 Needs a closer look

There is a confirmed potential panic in newly added vendored helper code and several downstream runtime Containerfiles still omit a package update step needed to meet the PR’s stated CVE-reduction intent.

Review details

Suppressed comments (4)

build/populator-controller/Containerfile-downstream:14

• This runtime stage installs tar but leaves the microdnf update step commented out, so already-installed base RPMs won’t get security errata at build time. Since the goal of this PR is CVE reduction, run microdnf -y update before installing additional packages.
  build/forklift-controller/Containerfile-downstream:15
• This runtime stage installs tar but leaves the microdnf update step commented out, so already-installed base RPMs won’t get security errata at build time. Since the goal of this PR is CVE reduction, run microdnf -y update before installing additional packages.
  build/ova-provider-server/Containerfile-downstream:14
• This runtime stage installs tar but leaves the microdnf update step commented out, so already-installed base RPMs won’t get security errata at build time. Since the goal of this PR is CVE reduction, run microdnf -y update before installing additional packages.
  build/hyperv-provider-server/Containerfile-downstream:14
• This runtime stage installs tar but leaves the microdnf update step commented out, so already-installed base RPMs won’t get security errata at build time. Since the goal of this PR is CVE reduction, run microdnf -y update before installing additional packages.

• Files reviewed: 43/460 changed files
• Comments generated: 0 new
• Review effort level: Lite

[aaaaaaaalex]

Most of this PR edits files the fork never builds

38 Containerfiles change here. Only 14 of them are ever built by this fork:
build-all-images-tigera / push-all-images-tigera / push-all-images-quay fan out over
TIGERA_IMAGES, and every one of those rules passes -f build/<name>/Containerfile or
Containerfile-upstream*. The string "downstream" appears nowhere in the Makefile's image
rules.

The other 24 are dead changes in this repo:

• every Containerfile-downstream (17 of them) — these are consumed only by the .tekton
  PipelineRuns' dockerfile parameter, and Konflux does not run on this fork. PR Address image CVE burden: float bases, trim runtime, unify Go toolchain #4's checks
  are CodeQL and the CLA, nothing else.
• build/virt-v2v/Containerfile, build/virt-v2v-rhel9/Containerfile,
  build/ovirt-populator/Containerfile — the entitlement-requiring variants; the fork builds
  the -upstream flavours instead.
• build/deep-inspection/* and build/deep-inspection-rhel9/* — deep-inspection is not in
  TIGERA_IMAGES at all, so none of its Containerfiles are built or pushed here.
• build/virt-v2v/Containerfile-upstream-fedora — commented out in full by this PR.
• build/forklift-operator-index/Containerfile:11 — adds microdnf -y update to a builder
  stage whose only output is operator.yaml, and operator-index is not in TIGERA_IMAGES
  either.

Two consequences worth acting on:

1. The CVE numbers can only cover the 14. Anything in the remediation doc that credits a
   scan improvement to a -downstream, deep-inspection, or entitlement-gated image is
   measuring an image this fork does not produce. Worth restating the claims against the 15
   images in TIGERA_IMAGES.
2. Dropping the 24 would make the PR much easier to review and remove the false impression
   that those images were hardened. If they are kept deliberately — to minimise drift against
   upstream — say so in the description, because nothing in the diff signals it.

Two unrelated items from the same pass:

• cmd/kubectl-mtv/kubectl-mtv is committed: an 84,461,490-byte Mach-O arm64 executable.
  The .gitignore entry added at .gitignore:10-14 has no effect while the file is tracked,
  and merging puts it in history permanently. Needs git rm --cached plus a rewrite over the
  branch.
• 17 of the 18 non-merge commits carry no Signed-off-by. No DCO check runs on the fork, so
  nothing flags it here, but it blocks reuse of any of these commits upstream later.
  git rebase --signoff over the branch fixes it cheaply.

Also, for the record: Copilot's seven microdnf --setopt comments are a false positive.
microdnf install -y --setopt=install_weak_deps=0 tar runs fine in both ubi9/ubi-minimal
and ubi10/ubi-minimal — verified in both images.

[Copilot]

🔵 Needs a closer look

The remediation plan still claims the root module uses a Go 1.26 directive, while the final implementation intentionally keeps it at Go 1.25.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

docs/security/cve-remediation-plan.md:215

• The final module directives are not unified on 1.26: go.mod is still go 1.25.0, while only .konflux/validation/go.mod is go 1.26.3. The implementation intentionally kept the root directive at 1.25 because it controls GODEBUG behavior for the replaced vsphere submodule, so this plan text (and the follow-up explanation below) now contradicts the code and the PR description; please update it to document the intentional split and the fact that the 1.26 builder still supplies the stdlib.

• Files reviewed: 43/460 changed files
• Comments generated: 0 new
• Review effort level: Lite

[anthonytwh]

Checked all of it against the branch. Your counts are exact:

Containerfiles changed by this branch : 38
changed AND built by this fork        : 14
changed but NOT built                 : 24

The 15th entry in TIGERA_IMAGES is forklift-operator-bundle, whose Containerfile this branch does not touch — which is where the 14/15 difference comes from.

The 24 are deliberate, and that is now written down

They are kept in step with upstream on purpose. Letting the two lineages diverge makes every future rebase harder and leaves a reader unable to tell which file is authoritative. You were right that nothing in the diff signalled it — there is now a "Which files this fork actually builds" section in both the PR description and docs/security/cve-remediation-plan.md, including the blunt version: nothing in those 24 should be read as an image this fork hardened.

That extends to builder-stage updates in files nothing here builds, like forklift-operator-index:11. The packages do not ship, so there is no CVE effect, but the cost is a few seconds of build time and the stage picks up a newer base if one lands — consistency over pruning it.

You caught a real number

The deep-inspection row in the P2 table (408 → 330 pkgs) credited an image this fork neither builds nor pushes, and which was in neither the 08-28 nor the 09-03 scan. Now footnoted in both places: the measurement is real and is why the flag stays in that file, but it is not an improvement this fork can claim.

I checked the rest rather than assuming — every image named in the results tables maps to a TIGERA_IMAGES entry, so that was the only one.

The assumption behind "not built = no effect", now verified

For an unbuilt Containerfile to affect one of the 14, a built image would have to pull content from another image. Every COPY --from= across the 14:

23 ×  --from=builder
 1 ×  --from=mtv-opa

Both resolve to stages declared in the same file; zero cross-image COPY --from=<image-ref>. The only place image identity crosses files is the operator bundle, and it embeds image references (ARG CONTROLLER_IMAGE=…) resolved by OLM at deploy time, not image content — pointing at upstream/Red Hat builds, not at anything our downstream Containerfiles produce.

The 80 MB binary is gone — force-pushed

cmd/kubectl-mtv/kubectl-mtv is stripped from all 18 commits, not just deleted in a follow-up. Branch is now c3f19ac65.

Verified before pushing:

commits on branch still containing it : 0
tracked in the tree                   : no
diff vs pre-rewrite backup            : cmd/kubectl-mtv/kubectl-mtv | Bin 84461490 -> 0 bytes
                                        1 file changed  (nothing else moved)
commit count / messages               : 18 before, 18 after, identical

Confirmed on the remote too — the binary no longer appears in the PR file list. .gitignore:12 now actually applies, since the rule was inert while the file was tracked.

For the record on how it got in: go build -mod=vendor ./... run inside cmd/kubectl-mtv during a verification step writes the binary into the module directory, and a git add -A in the next commit swept it in.

This force-push invalidated the inline comment anchors on this PR. Unavoidable with any rewrite, but worth knowing if a thread now points somewhere odd.

Still open: signoff

0 of 17 non-merge commits carry a Signed-off-by, not 17 of 18. Confirmed no DCO check runs here (the PR checks are CodeQL Analyze go/python and the CLA), so your point about blocking upstream reuse is the only thing at stake.

git rebase --signoff main fixes it, but it is a second rewrite and a second round of anchor invalidation. Happy to do it now while the disruption is fresh, or leave it — say which you prefer.

And thanks for the Copilot note

That matches what I found independently: microdnf accepts --setopt both before and after the install subcommand. The real constraint is the opposite of what those comments claimed — microdnf rejects install_weak_deps=False and needs =0, while dnf and yum take either.

[Copilot]

🔵 Needs a closer look

One or more issues must be addressed before approval.

Review details

Suppressed comments (6)

Previously missed (3) — in code that hasn't changed since the last review.

build/virt-v2v/Containerfile-upstream:28

• This shipped virt-v2v target still builds its four Go binaries in the earlier quay.io/centos/centos:stream9 stage with the distro golang package (lines 2–13), rather than go-toolset:1.26. The Makefile's build-virt-v2v-image target uses this Containerfile-upstream, so changing the runtime packages here does not achieve the PR's one-toolchain goal for the binaries copied into the final image. Please migrate this builder to the same 1.26 toolset (while preserving the required libvirt-devel headers) or explicitly exclude this shipped variant from the claim.
  build/virt-v2v/Containerfile-upstream-xfs:28
• The xfs variant has the same gap: its shipped Go binaries are compiled by quay.io/centos/centos:stream9's golang package in the builder above, not by go-toolset:1.26. This file is used for the virt-v2v-xfs image, so the P3 statement that all shipped builder stages use one Go toolchain is not true for this target. Migrate the builder to the 1.26 toolset or narrow the stated scope.
  docs/security/cve-remediation-plan.md:164
• This plan text no longer matches the Containerfiles: the downstream UBI bases were changed to :latest as well (for example, this branch changes the downstream vsphere populator base), so saying the registry.redhat.io bases were left pinned misstates the reproducibility and scope of P1. Please update the plan to describe the actual downstream state.

docs/security/cve-remediation-plan.md:215

• The final module directives were deliberately not unified on 1.26: the root module remains go 1.25.0, while .konflux/validation/go.mod is go 1.26.3. This section currently documents the reverted state and contradicts both the actual go.mod files and the rationale for avoiding Go 1.26's changed GODEBUG defaults.
  docs/security/cve-remediation-plan.md:202
• This syntax note is stale: the branch normalizes every install_weak_deps site to =0, not just two microdnf sites, and the current files no longer retain False. Please update the note so future readers do not infer that some remaining sites use the rejected microdnf spelling.
  docs/security/cve-remediation-plan.md:225
• The dependency table omits the golang.org/x/oauth2 bump from v0.23.0 to v0.36.0, even though this PR updates it to remediate CVE-2025-22868. Without this row, the security plan does not account for one of the Go findings addressed by the change.

• Files reviewed: 43/459 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

One or more issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 43/459 changed files
• Comments generated: 2
• Review effort level: Lite

[Copilot]

Copilot review overview

🟡 Changes recommended

One or more issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 3 · 7

Open (10)

• Restore nginx log directory ownership after dnf update · New
• go build ... github.com/open-policy-agent/opa builds the module root package, which is not the…
• microdnf treats --setopt as a global/application option; placing it after the install…
• This shipped virt-v2v-xfs build still compiles the Go binaries in the CentOS Stream 9 builder…
• This shipped virt-v2v build still compiles the Go binaries in the CentOS Stream 9 builder (`FROM…
• This downstream runtime stage uses ubi9-minimal:latest but doesn’t run microdnf update (it’s…
• This downstream runtime stage is on ubi9-minimal:latest but doesn’t run microdnf update (it’s…
• This downstream runtime stage now uses ubi9-minimal:latest but still skips microdnf update…
• This downstream runtime stage is now based on a floating tag (ubi9-minimal:latest) but it still…
• PR description states that registry.redhat.io base images in *-downstream Containerfiles remain…