When a security team scans a container image before it ships, they're answering one question: is this image safe to deploy? Once that image is running inside a Kubernetes cluster, a harder question takes over — is it still safe, and where exactly is it running? Snyk Container answers that second question through a Kubernetes-specific integration built around a lightweight, read-only workload agent called the Snyk Controller (previously shipped as an open-source project named kubernetes-monitor). Instead of relying on a new CI run or a fresh registry push to trigger a scan, the controller inventories workloads already running in a cluster, matches their images against Snyk's vulnerability database, and re-checks those same images every time that database changes. This piece breaks down how the integration is deployed, what access it requires, how it identifies workloads, and how results get surfaced — based on Snyk's publicly documented architecture, not a competitive comparison.
What Gap Does the Kubernetes Integration Actually Close?
It closes the gap between a point-in-time scan and the real-time state of a live cluster, because a registry or CI/CD scan only reflects what an image looked like at build time. A container that passed its pipeline scan in January can become vulnerable in July without anyone touching the code — a new CVE simply gets published against one of its base image packages or open-source dependencies. Without a runtime feedback loop, that disclosure sits in a vulnerability database while the affected image keeps running in production, and nobody is notified. The Kubernetes integration is Snyk's answer to that specific blind spot: it treats "what's deployed right now" as a first-class, continuously re-evaluated data set rather than a one-time snapshot taken during a build.
This distinction matters because most container vulnerabilities aren't introduced by a bad deploy — they're pre-existing risks in base images (Alpine, Debian, Ubuntu variants) or language dependencies (npm, pip, Maven packages) that get freshly disclosed after the image is already live. Gartner and various supply-chain incident postmortems have repeatedly pointed to this "scan-then-forget" pattern as a leading reason vulnerable containers stay in production for weeks or months after a fix is available.
How Is the Snyk Controller Deployed Into a Cluster?
It's installed as a Helm chart into a dedicated namespace — typically named snyk-monitor — using a Snyk-provided Helm repository. Setting it up requires two pieces of configuration generated from the Snyk organization's integration settings: an integration ID and a service account token, both passed to the Helm install as chart values (integrationId and dockercfg/serviceAccountApiToken depending on the chart version). Once deployed, the controller runs as a small set of pods inside that namespace and registers itself with the corresponding Snyk organization, after which the cluster appears as a distinct "target" in the Snyk UI, separate from any registry or SCM integrations already configured for that org.
Snyk documents support for the major managed Kubernetes distributions — Amazon EKS, Google GKE, Azure AKS, and self-managed/on-prem clusters — using the same Helm-based install path, and multiple clusters can report into a single Snyk organization simultaneously, each showing up as its own target so teams can compare exposure across environments (for example, a staging cluster versus a production cluster) from one dashboard.
What Permissions and Network Access Does the Controller Require?
It requires read-only Kubernetes RBAC permissions and outbound-only network access — it does not need cluster-admin, and it does not open any inbound ports. The Helm chart provisions a ClusterRole scoped to get, list, and watch verbs against workload resource types: Pods, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs, CronJobs, and ReplicationControllers. That's sufficient for the controller to see what's running and what image each workload references, but it cannot modify, create, or delete cluster resources.
On the network side, the controller only initiates outbound HTTPS connections (port 443) to Snyk's API endpoints to report findings — it never accepts inbound connections, which is why it can run behind a NAT gateway or a locked-down egress proxy with minimal firewall changes. For private registries, the controller reads the same imagePullSecrets already attached to workloads in the cluster to pull image manifests and layers for analysis, rather than requiring a separate set of registry credentials to be configured inside Snyk.
How Does It Identify and Continuously Monitor Workload Images?
It works by watching the Kubernetes API for workload specs, extracting the image reference (name, tag, and digest) from each one, and then pulling that image's manifest to build a dependency tree the same way Snyk's registry integrations do for a standalone image scan. Because the controller watches live workload objects rather than static YAML files, it picks up new deployments, rolling updates, and scaled-out replicas as they happen, and it resolves images down to their content digest so two differently-tagged references to the identical image layer are recognized as the same artifact.
The continuous part comes from re-evaluation, not re-scanning the cluster on a fixed clock alone: once an image's dependency tree is known to Snyk, that image is checked again automatically whenever Snyk's vulnerability and license database is updated — Snyk's feeds ingest new CVE and advisory data on an ongoing basis from sources including the National Vulnerability Database (NVD) and its own in-house research team. That means an image that scanned clean on Monday can generate a new alert on Thursday without anyone re-running a pipeline, redeploying, or manually re-triggering a scan, because the trigger is a change in vulnerability data, not a change in the cluster.
How Are Results Surfaced and Prioritized in the Snyk UI?
Results are grouped by cluster, namespace, and workload as "targets" so a security or platform team can see not just that a vulnerable image exists, but exactly where it's running — for instance, an image with a critical vulnerability might show as deployed across 14 pods in 3 namespaces spanning 2 clusters, all traced back to the same base image layer. Because the controller resolves images to their digest, Snyk deduplicates findings so the same underlying vulnerable layer isn't reported as dozens of unrelated issues just because it's referenced by multiple Deployments or reused across services.
Snyk's prioritization scoring in this view weighs factors like CVSS severity, exploit maturity, and whether a fixable version is available, which is Snyk's general vulnerability-prioritization approach applied to the runtime workload context rather than a Kubernetes-specific scoring model. Findings from the Kubernetes integration also link back to the same project view used for registry and CI scans of the same image, so a team can trace a running-container alert back to the Dockerfile or base image tag that introduced it, rather than treating runtime findings as an isolated data set.
How Safeguard Helps
Runtime image monitoring like this only closes the loop if the alerts it generates are actually triaged and acted on — and that's where visibility tools tend to hit a wall in real organizations: dozens of clusters, shared base images, and vulnerability counts that outpace the humans available to review them. Safeguard is built to sit downstream of exactly this kind of signal, correlating container vulnerability findings across every cluster and registry an organization runs, mapping them back to the specific base images, build pipelines, and teams responsible for remediation, and cutting through duplicate alerts caused by the same vulnerable layer being reused across dozens of workloads.
Rather than asking engineers to manually cross-reference a runtime alert against ownership records and deployment history, Safeguard automates that correlation so a newly disclosed CVE in a widely used base image gets routed to the right owners with the full blast radius attached — every affected cluster, namespace, and workload — instead of surfacing as one more item in an undifferentiated queue. For teams building a software supply chain security program that spans SCA, container, and runtime tooling, Safeguard's role is to turn continuous monitoring signals like these into prioritized, ownable remediation work rather than another dashboard to check.