Open-source dependency management for a Kubernetes cluster: the tools, by layer

There is no single best open-source tool for dependency management in a Kubernetes cluster, because a cluster has three different kinds of dependency and no tool covers more than one of them well. The versions you wrote down in Git are one kind. The versions actually running, which drift from Git the moment someone runs helm upgrade by hand, are a second. The packages inside the images, which nobody wrote down anywhere, are the third, and they are where the security advisories land.

The lists that rank for this question are "Kubernetes cluster management tools" roundups: Argo CD, Rancher, Karmada. None of them manages a dependency. This post sorts the open-source tools by which of the three layers they work on, with the commands, the current versions as of 2 November 2026, and what each one leaves to the next. StackRadar, our product, is in the third layer only, and the post says where it is the wrong tool.

The three layers, and the tools for each

The layers are in the order a dependency travels. A tag is written in Git, a controller deploys it, and the image it names carries a few hundred packages that were chosen by whoever built the base image. nginx:1.27-alpine, a small image, has 68 of them by Syft's count. A manifest that pins it says nothing about any of the 68, which is why the third layer needs a different kind of tool from the first two.

Layer 1: keep the versions in Git current

In a GitOps setup the fix for anything is a commit, so the first dependency tool is the one that opens the commit for you. Two do this for Kubernetes repositories.

Renovate

Renovate (Mend, AGPL-3.0, release 44.205.1 on 2 November 2026) opens pull requests for every version it can find in a repository. For Kubernetes the relevant managers are helmv3 for Chart.yaml dependencies (OCI charts are looked up through the docker datasource), helm-values for the image.repository / image.tag blocks in values.yaml, kubernetes for image tags and apiVersion fields in plain manifests, flux for HelmRelease chart versions and OCIRepository tags, and argocd for Application sources. The first two are on by default. The kubernetes, flux and argocd managers match no files until you give them a pattern, which is the step most people miss:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "kubernetes": { "managerFilePatterns": ["/^k8s/.+\\.ya?ml$/"] },
  "flux": { "managerFilePatterns": ["/^clusters/.+\\.ya?ml$/"] },
  "argocd": { "managerFilePatterns": ["/^argocd/.+\\.ya?ml$/"] }
}

What Renovate does well: it understands the GitOps objects themselves, it groups and schedules updates, and the regex manager covers whatever the built-in ones do not. What it does not do: it never looks at the cluster. A release installed by hand, or a tag the controller moved, is invisible to it.

Dependabot

Dependabot (GitHub, MIT core) added Helm on 9 April 2025. With package-ecosystem: helm it updates the dependencies in Chart.yaml and, per GitHub's docs, the Docker images referenced inside the chart. The docker ecosystem bumps image tags in Kubernetes manifests, one dependabot.yml entry per directory. The private-registry support for charts is HTTP basic auth only; an OCI chart registry has to be configured as a docker-registry instead.

version: 2
updates:
  - package-ecosystem: helm
    directory: /charts/app
    schedule: { interval: weekly }
  - package-ecosystem: docker
    directory: /k8s
    schedule: { interval: weekly }

Pick Dependabot when the repository is an application with a Dockerfile and a chart, you are on GitHub, and you want nothing to run. Pick Renovate when the repository is the GitOps repository: Dependabot has no idea what a HelmRelease or an Argo CD Application is.

The tools that skip the pull request

Three projects watch a registry and roll a new image out without a human in the loop. They are deployment automation rather than dependency management, but they come up in the same search and they overlap with Renovate on the image tag.

• Flux image automation (v1.3.0 of the controller, 24 October 2026) uses three objects: an ImageRepository scans a registry, an ImagePolicy picks a tag by semver, alphabetical or numerical rule, and an ImageUpdateAutomation rewrites the fields marked with a $imagepolicy comment and commits to Git. The commit is the audit trail.
• Argo CD Image Updater (v1.4.0, 22 October 2026) does the same for Argo CD Applications through ImageUpdater resources, with semver, newest-build, alphabetical, digest and calver strategies. Its default write-back method edits the Application in the cluster, which the project calls pseudo-persistent: a re-created Application loses the change. Use the git write-back for anything you care about. The project still describes itself as suitable for non-critical environments.
• Keel (MPL-2.0, keel-v1.2.3, 29 September 2026) needs no Git at all: an annotation such as keel.sh/policy: minor on a Deployment or Helm release, a registry webhook or a poll, and the workload is updated in place. It is the simplest of the three and the one with the least record of what happened.

Layer 2: find what is behind in the running cluster

Git says what should be running. The second layer checks what is. Start with Helm's own view, which costs nothing:

helm list -A

That gives the chart and app version of every release. It does not say whether a newer version exists, because Helm's dependency handling ends at install: helm dependency update resolves Chart.yaml into Chart.lock, and nothing in Helm ever looks again. Two tools fill the gap.

Nova

Nova (Fairwinds, Apache-2.0, v3.12.2 on 12 October 2026) reads the Helm releases in the cluster, looks each chart up on Artifact Hub by default or in the repositories you pass with --url, and reports the installed version, the latest, and whether the chart is deprecated. With --containers it does the same for image tags against their registries.

nova find --wide --format table            # Helm releases: installed, latest, deprecated
nova find --containers --format table      # image tags: current, latest, latest minor/patch
nova find --show-old --format table        # only the releases that are behind

Nova is a one-shot CLI: run it from a laptop or a CI job. It is the fastest answer to "which of our charts are behind", and it is the only tool here that knows a chart is deprecated. Note that from v3.12.0 its images moved to us-docker.pkg.dev/fairwinds-ops/oss/nova with no floating tags, so a CI job that pulled quay.io/fairwinds/nova:v3 needs a full version tag or a digest.

version-checker

version-checker (Jetstack, Apache-2.0, v0.11.0 on 26 June 2026) is the continuous version of the same check. It runs in the cluster, compares each container's tag with the latest in its registry (Docker Hub, Quay, GCR, ECR, ACR and any Docker V2 registry), and exposes the result as the Prometheus metric version_checker_is_latest_version, with a Grafana dashboard to read it. It also checks the cluster's own Kubernetes version against a release channel.

helm repo add jetstack https://charts.jetstack.io
helm install version-checker jetstack/version-checker

The binary checks only containers whose pod carries an enable.version-checker.io/<container> annotation unless it is given -a, --test-all-containers; the Helm chart sets that flag for you (its versionChecker.testAllContainers value defaults to true). Per-container annotations pin the comparison: pin-major, pin-minor, pin-patch, match-regex for tags like v1.3.4-debian-r30, and override-url for an image mirrored from somewhere else. Expect to write a few of those: a plain "is this the latest tag" comparison is wrong for every image that publishes several tag families.

kubent and Pluto: the dependency on the cluster itself

Every object in the cluster depends on an API version, and Kubernetes removes them on a schedule. Two tools find the objects a coming upgrade will break.

• kubent (DoiT, MIT, 0.7.3 of 30 August 2024, repository still active) reads the live cluster and Helm 3 release secrets by default, and manifest files with -f. It groups findings by the release that removes each API, and --exit-error makes it fail a CI job with exit code 200.
• Pluto (Fairwinds, Apache-2.0, v5.24.4 on 15 September 2026) is the static-analysis counterpart: it scans manifests and Helm charts in a repository, plus Helm releases in a cluster, and tells deprecated from removed apart. Its README explains why it does not simply ask the API server: the server converts an old apiVersion to the current one silently, so a cluster query under-reports.

kubent --target-version 1.37 --exit-error   # live cluster + Helm releases
pluto detect-files -d manifests/            # the repository, before it is applied

Layer 3: the dependencies nobody declared

Everything above compares version strings. The third layer is different in kind: the packages inside the image. A FROM debian:bookworm line pulls in a few hundred of them, the language layer adds the application's own, and none of them appear in a chart, a manifest or a Renovate pull request. When OpenSSL or glibc publishes an advisory, the question "which of our running pods has it" cannot be answered from Git. It needs an inventory of what is inside each running image, which is an SBOM, and something that matches the inventory against the advisory feeds as they change.

The open-source options are covered in depth in open-source vulnerability scanners for Kubernetes and self-hosted Kubernetes vulnerability management; the short version, as dependency tools:

• Syft and Grype (Anchore, Apache-2.0) are the building blocks: Syft writes a CycloneDX or SPDX SBOM for an image, Grype matches it. Pointing them at every running image, once per digest, and keeping the results is your pipeline to build.
• Trivy Operator (Aqua, Apache-2.0, v0.36.1 on 29 October 2026) scans running workloads in the cluster and stores a VulnerabilityReport per workload as a CRD. A new advisory is found on the next rescan; the reports are the latest state only, in etcd. The compare page goes through the operating cost.
• sbom-operator (0.48.0 on 27 October 2026) generates an SBOM with Syft for every image in the cluster and sends it to Git, an OCI registry, a ConfigMap or Dependency-Track (OWASP, Apache-2.0, 5.2.1 on 25 October 2026), which keeps the SBOMs and re-evaluates every component as the feeds change. The pair is the most complete open-source answer for SBOMs that go beyond containers; Dependency-Track does not know what a namespace or a Helm release is, so the mapping back to a workload is yours. We compare against it directly.
• StackRadar (AGPL-3.0, v0.3.0 on 1 November 2026) is this layer with the Kubernetes context attached. An in-cluster agent keeps one CycloneDX SBOM per running image digest; the server mirrors OSV.dev, EPSS and the CISA KEV catalogue and re-matches every stored SBOM when the mirror changes, so a new advisory shows the affected pods without a rescan. Each finding carries the Helm release that packaged the workload and the Argo CD application that delivers it, so the fix is a chart version and a helm, argocd or kubectl command. The Community Edition is one cluster, self-hosted from one Helm chart.

What StackRadar does not do, so the layers above stay necessary: it does not open pull requests, it does not know that a newer chart version exists, and it does not check API deprecations. If the question is "are we behind", Nova and Renovate answer it and StackRadar does not. If the question is "which running image carries a package that is being exploited, and what do I bump to make it go away", that is the one it is built for. The fix at this layer is always a new image, not a package upgrade in place; CVE patching in Kubernetes explains what "fixed in" means when the package comes from a distro.

Tools that come up and do not belong here

• Argo CD, Flux, Rancher, Karmada deliver and manage clusters; they do not track whether anything in them is behind. The image automation parts of Flux and Argo CD are the exception, covered above.
• Glasskube, a package manager for Kubernetes with dependency resolution, archived its repository on 14 June 2026. Do not start a new install on it.
• Kustomize manages configuration overlays, and its images field is a place Renovate and Flux can rewrite a tag, but it checks nothing.
• Trivy's misconfiguration scan and Kubescape are posture tools; Kubescape also scans images for vulnerabilities, but neither reports version drift.

A free stack that covers all three layers

Four tools, all free, none of them doing another's job. The place to spend money, if anywhere, is the last row: it is the only layer that changes daily without anyone touching Git or the cluster, and the only one where the list is long enough to need ranking by exploitation rather than by version number. The first three rows are solved problems with a maintained open-source tool each, and no platform does them better.

Frequently asked questions