[BUG]: Released operator image reports 2 HIGH findings already fixed on main

[lockwobr]

Summary

The published operator image reports 2 HIGH findings that are already fixed on main. No code change is needed; the released artifact simply predates the fix.

Detail

Scanning ghcr.io/nvidia/nodewright/operator:latest (digest sha256:38e9a79125633aa633f8e499306b2219c582c6f62a7bfe4083928212e70f74a7) with grype reports 4 fixable findings, all Go modules. The distroless base contributes none, which is the base doing its job.

Sev	Module in the image	ID	Fixed in
High	google.golang.org/grpc v1.82.1	GHSA-vp52-pcj8-j9qc	1.83.1
High	google.golang.org/grpc v1.82.1	GHSA-2v4p-qf9q-27wj	1.82.2
Medium	google.golang.org/grpc v1.82.1	GHSA-qc2q-p7wx-3px3	1.83.1
Medium	go.opentelemetry.io/otel v1.43.0	GO-2026-5158	1.44.0

operator/go.mod on main already pins google.golang.org/grpc v1.83.2 and go.opentelemetry.io/otel v1.44.0, both past every fixed version above. All four findings therefore clear on the next operator release.

Why file this

Two reasons worth recording rather than leaving implicit.

First, it is the actionable half of a real gap: the fix exists and users running the released image do not have it. Cutting a release is the remedy.

Second, it establishes what the scan in #627 measures. Scanning :latest reports on the released artifact, not on main. That is the correct target for a supply-chain view, and it means a finding here can mean "already fixed, not yet shipped" rather than "unfixed". Anyone triaging a finding from that workflow should check main before writing a VEX statement, because a stale-release finding needs a release, not a suppression.

How to reproduce

grype ghcr.io/nvidia/nodewright/operator:latest --only-fixed -o json \
  | jq -r '.matches[] | "\(.vulnerability.severity)\t\(.artifact.name) \(.artifact.version)\t\(.vulnerability.id)"'

grep -E 'google.golang.org/grpc|go.opentelemetry.io/otel ' operator/go.mod

Additional context

Found while implementing #627. Counts come from a vulnerability database six days stale at the time of scanning. Companion issue for the agent image: #628.

[lockwobr]

Status check: fixed at head, not yet in any release. Keeping this open deliberately, because the exposure it describes is still live.

The bump landed after operator/v0.19.0 was cut, and that tag is what :latest currently resolves to:

operator/v0.19.0 (newest tag, what :latest points to):
	go.opentelemetry.io/otel v1.43.0
	google.golang.org/grpc v1.82.1

main:
	go.opentelemetry.io/otel v1.44.0
	google.golang.org/grpc v1.83.2

So there is no code work left here, and anyone pulling :latest today still gets the vulnerable versions. This closes on the next operator release, without a PR.

Two reasons for not closing it early rather than one:

First, the issue tracks user-visible exposure, not repository state. Closing it while the published artifact is still affected would record the problem as solved for people who are still running it.

Second, #630 gates on this. Its precondition is that #628 and #629 are closed and the scan is quiet. If this closed now, that precondition would be satisfiable while :latest still reports 2 HIGH, and whoever acted on it would switch on a release gate that fails on the first run.

This is also the worked example the nodewright-managing-openvex skill cites for "check main before writing a VEX statement": a finding whose remedy is a release, not a suppression. Writing a statement asserting we are not affected would be false, since we simply have not shipped the fix.

[lockwobr]

Resolved by the operator v0.20.0 release, as predicted: no code change was needed, only a release.

• ghcr.io/nvidia/nodewright/operator:v0.20.0 (= :latest, index digest sha256:5ddfc211d3de8861c5c1721c61139f65e0a733c35bad4b31960dd8fe44d545a9) is built from operator/go.mod with google.golang.org/grpc v1.83.2 and go.opentelemetry.io/otel v1.45.0, past every fixed version in the table above.
• A local grype scan of that digest with .grype.yaml and .openvex.json (DB built 2026-10-06) reports none of the four IDs, no fixable findings, and nothing HIGH or above. The one remaining match is a Low with no upstream fix (GO-2025-3547, k8s.io/kubernetes).
• The on-demand Image Vulnerability Scan run (https://github.com/NVIDIA/nodewright/actions/runs/37573069823) marked code scanning alerts Bump golang.org/x/net from 0.26.0 to 0.33.0 in /operator #1 and feat(agent): add container build ci on commit with attestation #2 (the two grpc HIGHs) fixed, and leaves no open grype alerts for either the operator or the agent image.

No .openvex.json statement was written for any of these, per the "already fixed on main" rule: the remedy was shipping the fix.