SBOM for Cloud-Native Applications: Kubernetes, Helm Charts, and Container Registries

The Layered SBOM Problem in Kubernetes

A Kubernetes deployment has SBOM complexity at multiple levels. At the container image level, each image contains OS packages, language runtimes, and application dependencies — each with their own vulnerability and license considerations. At the Helm chart level, a Helm chart declares dependencies on other charts, creating a dependency graph analogous to a software package manager's dependency tree. At the cluster infrastructure level, the Kubernetes distribution itself (Amazon EKS, Google GKE, Azure AKS, or self-managed) contains components with their own vulnerability exposure.

SBOM Generation Strategies for Cloud-Native

The most effective approach is a layered strategy. Generate image SBOMs at build time using Syft or Trivy, capturing all layers of each container image. Store these image SBOMs in your container registry alongside the image — most modern registries support OCI annotations for attaching SBOMs. At deployment time, resolve the cluster-level composition: which image versions are actually running, including sidecar injections from service mesh controllers that may not be visible in the application's Helm chart. Use tools like Trivy Operator or commercial platforms to continuously scan running workloads in the cluster.

Sigstore and SBOM Attestation

In cloud-native environments, the integrity of SBOMs is as important as their content. An SBOM that could have been tampered with is worse than no SBOM — it provides false confidence. The Sigstore project (cosign, rekor, fulcio) provides cryptographic attestation for container images and their associated SBOMs. By signing SBOMs and attaching them as OCI attestations, you create a verifiable chain of custody from build to deployment. CISA has incorporated Sigstore-style attestation into its supply chain security guidance.

Continuous Monitoring for Cloud-Native

Cloud-native environments are dynamic — workloads scale, new images are deployed, nodes are replaced. Traditional point-in-time scanning does not keep up with this pace. Tools like Trivy Operator, Starboard, and commercial platforms provide continuous scanning that runs against the current state of the cluster, alerting on newly deployed vulnerable images and tracking vulnerability status across the fleet of running containers. Integrating this continuous scanning output with your central SBOM management platform gives you a complete picture of your cloud-native risk posture.