An SBOM you generated in CI describes an image you built. A Kubernetes SBOM describes the cluster: every image the kubelet is running — yours, the ingress controller's, the monitoring agent's, the sidecar the mesh injected — with its packages, versions and licences, attached to the namespace, workload and Helm release that runs it. StackRadar generates that inventory automatically with Syft, keeps one CycloneDX 1.6 document per image per cluster, and re-matches those documents against new advisories so the SBOM is the thing that stays current, not a scan report that expires.
One SBOM per running image
The scanner keys everything on the image digest, not the workload. One image running in five namespaces is one pull, one Syft run, one SBOM — and one finding when a CVE lands, shown against all five places it runs. The inventory the scanner reports alongside the SBOMs is what makes that attribution possible: namespaces, workloads and their containers, the Helm release that packaged each one, the ArgoCD application that delivers it. Coverage is honest by construction — the dashboard shows scanned-versus-discovered as a fraction, so an image the scanner could not pull is visible as a gap, not silently absent.
CycloneDX 1.6, generated by Syft
The scanner embeds Syft, Anchore's open-source SBOM generator, and emits CycloneDX 1.6 JSON — validated against the official schema on upload. Every component carries a PURL with its ecosystem and distro (pkg:apk/alpine/nginx@1.27.5-r1?distro=alpine-3.21.3), which is what the matcher evaluates advisory ranges against, plus a CPE for advisories published without one. The CycloneDX reference has a real, downloadable example generated from a public image and walks through every field that matters.
You can also generate one yourself, for a single image, in one line:
syft registry:docker.io/library/nginx:1.27-alpine \
--platform linux/amd64 -o cyclonedx-json@1.6 > nginx.cdx.jsonStackRadar's upload endpoint accepts SBOMs from any generator, so images built and scanned in a pipeline can be attributed to the cluster that runs them without the scanner pulling them again.
The SBOM is what stays current
A scan result answers one question at one moment. Because StackRadar keeps the SBOM, three things happen without any rescan:
- New advisories are matched in place. The OSV.dev mirror updates, the stored components are re-evaluated, and the finding appears against the workloads that run the image.
- Package search across the fleet. When the next Log4Shell names a library, search it and read the blast radius off the image and workload counts — including which versions are affected and which are already clean.
- History. Each SBOM is dated and superseded, never overwritten, so "what was running on 3 March?" has an answer: 30 days back on the free plan, a year on Pro, two on Business.
SBOMs a regulator will accept
The EU Cyber Resilience Act requires a machine-readable SBOM for products with digital elements, and its vulnerability-reporting duties start on 11 September 2026. For a service delivered on Kubernetes, the SBOM that matters is of the images that run, and the reporting duty needs to know within 24 hours which of them a newly exploited vulnerability affects. Both are what this inventory is for; the CRA post goes through the obligations in detail. Everything you upload is stored and processed in the EU.
Get an SBOM of your cluster in ten minutes
helm install stackradar-scanner oci://ghcr.io/lockdep/charts/stackradar-scannerThe quick-start walks through the API key and the pinned chart version. For a one-off inventory from your laptop without installing anything, the free StackRadar CLI scans the running cluster and reports findings, though it does not keep the SBOMs. And for the tooling landscape — Syft, Trivy, docker sbom, cluster-level generators — see SBOM tools compared.
Frequently asked questions
What is a Kubernetes SBOM?
A Kubernetes SBOM is a software bill of materials for what a cluster is actually running: one inventory per container image in use, listing its OS packages, language dependencies, versions and licences, tied to the workloads, namespaces and Helm releases that run it. It differs from a build-time SBOM in that it is generated from the image digests the kubelet reports, so it covers sidecars, add-ons and third-party images nobody in your organisation built.
How do I generate an SBOM from a container image?
Run Syft against the image: `syft nginx:1.27 -o cyclonedx-json > sbom.json` produces a CycloneDX SBOM; `-o spdx-json` produces SPDX. Trivy does the same with `trivy image --format cyclonedx nginx:1.27`, and `docker sbom` wraps Syft. To do it for every image running in a Kubernetes cluster, the StackRadar scanner runs Syft in-cluster automatically and lets you download each image’s CycloneDX SBOM from the dashboard.
Which SBOM format should I use for containers, CycloneDX or SPDX?
Either is accepted by regulators and both are ISO/ECMA standards; the choice is about tooling. CycloneDX was designed for security use cases, carries vulnerability and VEX data natively, and is what most container scanners emit by default. SPDX began as a licence-compliance format and is common in the Linux Foundation ecosystem. StackRadar generates and ingests CycloneDX 1.6; Syft can convert between the two if a customer asks for SPDX.
Why keep the SBOM instead of the scan result?
A scan result is true for the moment it was produced and stale the next time an advisory is published. An SBOM is a fact about the image that never changes, so it can be re-matched against tonight’s advisories without pulling or rescanning anything. Keeping the SBOM also gives you a dated record of what was running when — which is what an auditor, a customer security questionnaire, or an EU Cyber Resilience Act reporting duty actually asks for.
Does an SBOM contain my source code or secrets?
No. An SBOM contains package names, versions, licences, identifiers such as PURLs and CPEs, and dependency relationships. It contains no source code, no file contents, no environment variables and no secrets. That is why uploading an SBOM for vulnerability matching is safe in a way that uploading the image is not.
Is an SBOM required by law?
In the EU, the Cyber Resilience Act requires manufacturers of products with digital elements to produce a machine-readable SBOM covering at least top-level dependencies, with reporting obligations applying from 11 September 2026 and full obligations from December 2027. In the US, federal procurement guidance under Executive Order 14028 asks suppliers for SBOMs. In both cases the SBOM must be for what you ship — for a Kubernetes-delivered service, that means the images that run.