Common questions
What is an SBOM?
A Software Bill of Materials: the list of everything inside a container image — OS packages, libraries, runtimes, their versions, and licenses. It contains only names and versions, never source code, secrets, or image contents, which is why storing it outside the image is safe.
How does the scanner work?
It runs inside your cluster, scans each new image with Syft as it appears (plus a full sweep every 6 hours), and uploads only the resulting SBOM together with what is running where — to the StackRadar server, which is yours when you self-host and ours on the cloud. Vulnerability matching happens there. The architecture page walks through each step.
Where does the vulnerability data come from?
From OSV.dev — an open, public vulnerability database run by Google. It gathers security warnings from many sources: GitHub Security Advisories, Linux distributions (Debian, Alpine, Ubuntu, and others), and package ecosystems like npm, PyPI, Go, Maven, RubyGems, and crates.io. The StackRadar server keeps its own always-fresh mirror of these 900K+ warnings (a self-hosted install mirrors the ecosystems you choose) and checks your dependency lists against it. Because the data is open, there is no black box: every finding links to its public advisory, and you can double-check any result yourself on osv.dev.
How do I know what to fix first?
Findings are ranked by a risk score that combines three things: how bad the flaw could be (its CVSS severity score), how likely attackers are to actually use it (its EPSS probability, updated daily), and whether attackers are already using it right now (the CISA Known Exploited Vulnerabilities list). So a flaw being used in real attacks outranks a scary-sounding one nobody touches, and your list starts with the findings that matter.
Most of my findings are in the base image. What do I do with those?
StackRadar separates them. Every findings list opens on the packages your own build added, which are the ones a dependency bump fixes, and folds the base image’s operating-system packages and runtime tooling into a bucket that is counted, one click away and never hidden. Anything being exploited is shown whichever bucket it is in. For images you build, it then checks what rebuilding on a newer base image would remove and tells you the number; for third-party images it tells you which chart or image upgrade does the same.
Which Kubernetes distributions are supported?
The scanner works on any standard Kubernetes cluster — EKS, GKE, AKS, DigitalOcean Kubernetes, k3s, kind, and self-managed clusters. It uses the standard Kubernetes API and its access is read-only: it lists and watches pods, plus optional read-only lookups of workload controllers and ArgoCD applications for attribution. It never creates, modifies, or deletes anything. The self-hosted edition needs Kubernetes 1.25 or newer.
Does it support private container registries?
Yes. The scanner automatically uses the same credentials your pods already use (their imagePullSecrets) when it pulls images to read their contents. This works with any standard registry — ECR, GCR, Docker Hub private repos, GitHub Container Registry, and self-hosted registries.
How often does it scan?
The scanner works in two complementary modes: it watches for pod events in real time so new or updated images are scanned as soon as they appear, and it performs a full cluster sweep every 6 hours (configurable via Helm values) to ensure nothing is missed. Each distinct image is scanned once per cluster. You can also choose which namespaces are scanned using include or exclude lists, and skip specific images by name pattern.