Securing Your Helm Chart and Container Image Supply Chain

A supply chain attack doesn’t need to breach your infrastructure directly — it just needs you to helm install something that looks legitimate. Sophisticated threat actors have increasingly targeted Kubernetes deployments this way: compromising container images, Helm charts, and operator packages upstream, so the malicious payload arrives through a process your team trusts and runs routinely, rather than through an attack your defenses are watching for.

Why this attack vector works so well against Kubernetes specifically

Kubernetes deployments involve an unusually long chain of trusted inputs: base images, application dependencies baked into those images, Helm charts pulling in subcharts, operator packages with their own permissions and reconciliation logic. Each link in that chain is a potential compromise point, and most teams verify none of them beyond “does this come from a repository that sounds official.” A compromised base image on a public registry, or a popular Helm chart with a malicious update pushed to a maintainer account, can reach production through a completely routine deployment, with no anomalous-looking action on your team’s part at all.

The specific defenses that matter, in order of impact

Pin image digests, not tags. A tag like :latest or even a specific version tag (:2.4.1) can be repointed to a different image by whoever controls the registry entry — a digest (@sha256:...) is immutable and guarantees you’re running exactly the bytes you verified, not whatever currently sits behind that tag. This is the single highest-leverage, lowest-effort change most teams can make.

Verify image signatures at admission. Signing images (with tools like Sigstore/Cosign) and enforcing signature verification at admission means an unsigned or improperly signed image simply can’t be scheduled, regardless of how it arrived. This closes the gap where a compromised registry entry, even if caught later, could otherwise have already been deployed.

Scan images for known vulnerabilities before deployment, not just at build time. A CI-time scan catches what was known at build time; registries and images sit around for a while, and vulnerabilities get disclosed continuously. Periodic re-scanning of what’s actually deployed catches drift between “was safe when built” and “is safe now.”

Audit Helm chart sources, especially subchart dependencies. A chart you’ve vetted can still pull in subcharts you haven’t looked at closely — helm dependency list surfaces the full tree, and it’s worth actually reading it rather than trusting that a popular top-level chart implies safety all the way down.

Scope operator permissions deliberately, the same way you would application RBAC. Operators often request broad permissions “to be safe,” and because they’re infrastructure rather than application code, that request gets rubber-stamped more often than an application ServiceAccount’s would. The same RBAC audit discipline that applies to your own workloads applies just as much to third-party operators — arguably more, since you didn’t write the code and can’t easily verify it only uses what it asks for.

Runtime detection as the backstop, not the primary defense

Even with every deployment-time defense above in place, a sufficiently novel supply chain compromise can still get through — which is exactly why runtime security matters as a complementary layer, not a redundant one. A compromised image that passed every static check will still, once running, exhibit runtime behavior that doesn’t match a legitimate version of that workload — an unexpected outbound connection, an unfamiliar process being spawned. Deployment-time defenses reduce how often you need runtime detection to catch something; they don’t make it unnecessary.

What this looks like for a small team without a dedicated security function

The full defense-in-depth picture above is a lot to implement at once, and for a small team it’s worth sequencing rather than attempting all at once. Digest pinning costs almost nothing and should happen first. Signature verification at admission is the next highest-leverage step, and most managed Kubernetes offerings have reasonably turnkey paths to enable it now. Helm dependency auditing and operator RBAC scoping are more manual but worth doing at least once per major dependency, revisited when you upgrade. Runtime detection is the last piece to add, both because it requires more ongoing tuning and because the earlier layers reduce how much it needs to catch.

Frequently asked questions

Is digest pinning enough on its own, without signature verification? It’s necessary but not sufficient — pinning to a digest guarantees you’re running exactly what you verified at the time you pinned it, but doesn’t verify that image was legitimate in the first place. Signature verification addresses that earlier question; the two are complementary, not substitutes.

How often should Helm charts and their dependencies be re-audited? At minimum, on every major version bump — chart maintainers change, dependencies get added, and a chart that was safe at version 1.0 isn’t guaranteed to still be safe at 3.0 just because you trusted the earlier version.

Do public, popular Helm charts get compromised often in practice? Rarely relative to their total usage, but the impact when it happens is large precisely because popularity is what makes a chart an attractive target — a compromise in a widely-used chart reaches far more clusters than one in an obscure one.

Is this worth the effort for a team running a handful of well-known, popular images? Even “well-known” images benefit from digest pinning and signature verification specifically because popularity is what makes them attractive targets — the effort scales with what you have to lose, not with how obscure your stack is.

See runtime anomalies alongside the rest of your fleet’s health signals — start free with one cluster.