Summary

make bom-docs against the live registry produces this entry under gpu-operator:

- vgpu-manager

A bare vgpu-manager with no registry, no tag, and no digest. This is misleading on the published BOM (docs/user/container-images.md) — readers cannot tell what registry/version this would actually pull from, and the value alone tells them nothing about the deployed bytes.

Root cause

The GPU Operator chart values include a section roughly shaped like:

vgpuManager:
  enabled: false
  image: vgpu-manager
  repository: ...   # may or may not be present in our values
  version: ...      # may or may not be present in our values

The BOM tool's CRD-style triplet collector (pkg/bom.combineCRDTriplet) walks every YAML mapping looking for image/repository/version siblings. When the chart's vgpuManager block is rendered without our values overriding it, only the image: vgpu-manager placeholder is present (no repo, no version), so the combiner emits the bare scalar.

Because vgpuManager.enabled: false by default, the image is never actually deployed — the BOM tool can't tell that. It captures the placeholder either way.

Why it matters

• The published BOM lists an image AICR doesn't deploy, eroding the artifact's authority.
• The recipes/manifest_images_test.go regression test added in fix(recipes): fully-qualify image refs in component manifests #761 only walks recipes/components/*/manifests/*.yaml, so it doesn't catch helm-rendered output drift like this.
• Future digest-pinning work (Pin chart versions for all components in recipes/registry.yaml #748) would treat this as a real image and try to resolve it.

Proposed fix

Two complementary directions, either or both:

1. Skip disabled chart sections. The BOM tool walks the rendered Helm output, but disabled components still have their image fields rendered as scalars (Helm doesn't strip them). The cleanest signal is "did this manifest actually produce a Pod-shaped resource?" Filter at the renderer level: skip any image: whose enclosing mapping is under a key whose value resolves to enabled: false. (Brittle — relies on a chart-by-chart convention.)
2. Reject obviously-non-image scalars. Tighten pkg/bom.isLikelyImage to require either a :tag, an @digest, OR a registry-host first segment. A bare vgpu-manager has neither, so reject it. Single-segment Docker Hub refs (nginx, busybox:1.36) still pass because they carry a tag or canonicalize via the existing library/ rule. (More general; lower false-positive risk.)

I'd lean (2). Worth pairing with: the pkg/bom regression test should be extended to walk make bom's helm-rendered output (against a kwok cluster?) so this class of drift fails in CI rather than only surfacing on manual inspection.

Related

• fix(recipes): fully-qualify image refs in component manifests #761 — fixed CRD-style triplet handling end-to-end; this issue is the next layer of the same family of bugs.
• [Epic]: Software supply chain security: visibility, reproducibility, verification #739 — supply-chain epic; published BOM accuracy is part of Stage 1.
• Digest-pin explicit image references in recipes #749 — digest pinning will need this fixed to avoid trying to resolve a digest for a bare placeholder.