🌱 Publish SBOMs out-of-band so image manifests stay plain (unblocks the SBOM gap without reopening #3760)

[clubanderson]

Raised while responding to CNCF TAG-Security review of the security self-assessment (cncf/toc#2286), which records "No formal SBOM" as a gap.

Why SBOM is currently disabled — and why it is not simply a flag to flip

.github/workflows/docker.yml sets provenance: false / sbom: false in four places (:295,346,631,818). This is not a deprioritization of supply-chain metadata. It is the fix for #3760 (closed): build-push-action attaches attestations by default, an attestation can only be carried by an OCI image index, and that index form let a COPY --from layer ship an overlayfs metacopy redirect for /usr/local/bin/hive — which containerd/k3s and rootless podman present as non-executable, crash-looping the image.

Re-enabling the flags would reintroduce a shipped-image crash loop. The workflow comments document this at length.

Proposal: generate the SBOM out-of-band

Decouple SBOM generation from the image build so the published manifest stays a plain image:

1. Add a post-build job running anchore/sbom-action (syft) or aquasecurity/trivy-action against the built image.
2. Publish the SBOM (SPDX or CycloneDX) as a release asset and/or workflow artifact — not as an OCI attestation.
3. Optionally sign it with cosign as a detached signature, again avoiding the index form.
4. Add a regression assertion that the published manifest media type remains application/vnd.oci.image.manifest.v1+json and not ...index.v1+json, so a future well-meaning change cannot silently reintroduce stable/candidate/edge images: hive binary fails exec with EPERM from /usr/local/bin/hive (works when copied elsewhere) #3760.

Step 4 matters as much as the SBOM itself — it converts a comment-documented constraint into an enforced one.

Done when

• An SBOM is published per release for each image
• The image manifest media type is asserted in CI
• security-self-assessment.md Metadata row records where to find the SBOM