In a recent PlatformEngineering.org virtual webinar, Nigel Douglas, Head of Developer Relations at Cloudsmith, led a deep dive into an increasingly critical topic: Identifying vulnerabilities in public Kubernetes Helm charts (you can watch it on-demand here).

With the growing popularity of tools like artifacthub.io, many teams consume Helm charts without fully understanding the potential security risks they introduce. Over the course of this 45-minute session, Nigel explored practical techniques for analysing, scanning, and securing Helm charts - especially those sourced from public repositories. From using tools like Trivy and helm-diff to implementing proper upgrade strategies and understanding runtime behaviour, the webinar provided a wealth of actionable insights for platform engineers, DevOps teams, and security-minded developers.

Although the live session covered a broad range of security concerns, several thoughtful questions from the audience remained. We've gathered them here (along with Nigel’s direct responses) to ensure you don’t miss any of the knowledge shared during this engaging and educational event.

What’s your take on maintaining and upgrading helm charts after we've installed them? How important it is, how often it should be done, how it should be done, etc.

Maintaining and upgrading Helm charts after installation is essential for keeping your Kubernetes workloads secure, stable, and compatible with the evolving ecosystem. Over time, charts can reference outdated container images or deprecated Kubernetes APIs, which may expose your apps to vulnerabilities or operational issues. Saying that, regularly upgrading your charts can ensure that your apps benefit from upstream improvements such as bug fixes, performance enhancements, or improved and updated best practices as the projects evolve in maturity.

In general, upgrades should be considered every few weeks for critical applications, or at least quarterly for lower-risk workloads. Security patches, however, should be applied immediately when relevant. The upgrade process should involve reviewing chart release notes, performing a helm upgrade --dry-run, as discussed in the webinar, and ideally using tools like the helm-diff plugin to understand exactly what will change. Automation can also help, using tools like Renovate or GitOps pipelines to track and apply updates. Ultimately, treating Helm charts as living infrastructure (not one-time installations) is the real key to ensuring long-term reliability and security.

Isn't the common factor of all these vulnerabilities a careless/knowledge of the result of a deployment?

We could say the same about quite a few security-related configurations. Many Helm-related vulnerabilities stem from a lack of awareness about the full implications of what a chart deploys - whether that’s in overly-permissive RBAC rules, exposed secrets, or insecure defaults. Helm makes deployment easy, but that convenience can lead to oversight if users don’t audit the rendered manifests or understand what the chart is configuring in the cluster. It’s why tools like helm template, helm diff, and scanners like Trivy are so valuable: they help surface risky configurations before they’re applied. Ultimately, secure Helm usage depends as much on the operator’s vigilance as it does on the chart’s design. As seen with the Microsoft research last month, this type of insecure configuration is rampant in the software supply chain since we consume charts that often don’t enforce these controls by default.

Could you please share recent Kubernetes vulnerabilities and top mitigation techniques?

To find recent Kubernetes-specific vulnerabilities, the best sources are the Kubernetes CVE feed, the NIST’s NVD Database, and tools like Trivy or kubescape that maintain up-to-date vulnerability databases. Top mitigation techniques include enforcing least privilege access (via RoleBindings or OPA & OPA Gatekeeper), enabling audit logging, restricting container capabilities, setting readOnlyRootFilesystem: true, and scanning workloads and Helm charts regularly. Incorporating security checks early in the CI/CD pipeline is also key to reducing risk before deployment.

Is there any website or page where we can find Kubernetes vulnerabilities?

Yes, the Kubernetes project provides an official, auto-refreshing CVE feed that publicly lists known Kubernetes vulnerabilities. Since 2022, this feed has been maintained to help users stay informed about security issues as they arise. You can access it here: https://kubernetes.io/blog/2022/09/12/k8s-cve-feed-alpha. It's a valuable resource for tracking vulnerabilities in the Kubernetes ecosystem and planning timely mitigations.

How can we verify that this Helm chart is not vulnerable to attacks? What steps should we follow to perform this assessment?

After scanning your Helm chart with a trusted security tool like Trivy, it's important to address all vulnerabilities marked as HIGH or CRITICAL. Once remediated, scan the chart again to confirm that those issues have been resolved. Rather than repeating this process manually each time, we recommend uploading your updated chart to a secure, centralized artifact management platform like Cloudsmith. This enables you to maintain control over your chart’s integrity and trustworthiness by signing the chart and verifying its provenance. Relying on a centralized solution (rather than public repositories like ArtifactHub) also gives you clear insight into the chart’s Data Provenance: a detailed record of its origin, changes, and associated contributors. This approach helps ensure that the charts you distribute and deploy are secure and free from known vulnerabilities.

How can you verify that the helm chart does not perform egress calls to sources that you don't want as an organisation? Is that through scanning or network policies on egress traffic?

To verify that a Helm chart doesn't allow or initiate egress calls to unwanted external sources, you should use a combination of static analysis and runtime controls. First, during pre-deployment, tools like Trivy can statically scan rendered Kubernetes manifests (helm template ./mychart | trivy k8s --security-checks config -) to detect misconfigurations - like containers without egress restrictions or unrestricted network policies. However, static scanning alone won't always catch dynamic behaviours (like runtime DNS lookups or hardcoded IPs).

How do you scan the chart with Trivy?
Do you need to install Trivy on a cluster?

In our webinar, we used Trivy as a standalone scanner installed on an Ubuntu machine using snap install Trivy. While Trivy does offer a Kubernetes Operator for in-cluster scanning, you don't need to install it on a cluster to analyze Helm charts. For example, we scanned Kubernetes-specific misconfigurations (like Secrets exposed in plain text) by running helm template ./mychart | trivy k8s --security-checks config -, which renders the chart and scans the output. Alternatively, if you’ve already used helm template to export the chart into a single YAML file, you can scan it directly with trivy config --severity HIGH,CRITICAL my-sample-chart.yaml to focus on high and critical severity issues. This approach makes it easy to evaluate chart configurations without needing to deploy them.

To enforce egress control at runtime, it's best to implement Kubernetes Network Policies, ideally with a CNI plugin like Calico. These policies can restrict which destinations pods are allowed to contact, based on CIDRs, namespaces, or label selectors. Defining strict egress policies ensures that, even if a chart includes or results in outbound traffic, that traffic is only permitted to destinations your organisation allows. This dual-layered approach (scanning and runtime restriction) is the most reliable way to prevent unintended or insecure egress behaviour.

What do you use to scan the Helm charts?

We primarily used Trivy to scan Helm charts for known vulnerabilities and insecure configurations, but there are several other tools that complement this process. KubeSec analyses Kubernetes YAML (including rendered Helm templates) for security risks. Datree focuses on validating Helm charts against Kubernetes best practices - checking for things like missing resource limits, privileged containers, HostPath usage, and other misconfigurations. For future-proofing, Pluto identifies deprecated or removed Kubernetes APIs within your charts, which helps avoid issues during cluster upgrades. Finally, while not a security tool, helm lint ensures your chart is syntactically valid - important for catching simple issues before they affect your deployments. Together, these tools offer a comprehensive approach to Helm chart assessment.

Are there any auditing tools yet that run a helm chart and show all of the open ports on the container vs. just what is mapped in the helm chart? Or is that pretty exclusive to Kubernetes network security programs?

This is a great question! Currently, auditing open ports at runtime (beyond what's declared in the Helm chart) is generally outside the scope of Helm-specific tools. Helm templates only define what's supposed to be exposed (e.g. via containerPort, hostPort, or Service definitions), but they can't catch what a container actually opens internally at runtime.

To identify all open ports inside a container, including those not exposed via Kubernetes objects, you’d typically use Kubernetes runtime security tools or network observability solutions, such as:

Cilium with Hubble: Provides deep network visibility and can monitor actual traffic flow, including unexpected egress/ingress.
Calico with Flow Logs: Can also audit real network traffic at the pod level.
Falco (by Sysdig): Can detect unexpected network behaviour like a container listening on unusual ports.
Kubebench or kube-hunter: While more focused on security posture and cluster vulnerabilities, these tools from the team at Aqua Security can help detect misconfigurations that lead to unintended exposure.

If you’re looking to compare what’s declared vs. what’s actually open, a combined approach works best. You can use helm template or helm show values to audit the declared ports before deploying the chart in a sandbox cluster. Running tools like netstat, ss, or nmap inside the container (or from another pod) to observe real ports in use. It's your responsibility then to monitor the traffic using a CNI-based tool like Cilium or Calico for the real-time egress/ingress behaviour. In short: yes, it’s more in the domain of Kubernetes network security tools than Helm itself, but combining both layers provides the most insight.

Is it good practice to deploy the API management server to safeguard the Kubernetes pods?

Yes! Deploying an API management server can be a strong security and governance practice in Kubernetes, especially when your workloads expose APIs. Tools like Kong, Apigee, or Tyk add layers of protection by enforcing authentication, rate limiting, and monitoring before traffic reaches your pods. They’re particularly valuable for public or partner-facing services where access control and visibility are critical. However, API gateways should complement (and not replace) the core Kubernetes security controls like network policies, pod security settings, and runtime protection. Used together, they form a more comprehensive and effective security strategy.

The event was a great learning experience. What is the 'End Goal' of this event? How long would you continue to have such informative sessions?

At Cloudsmith, we regularly host webinars focused on securing the software supply chain, which you can explore at cloudsmith.com/webinars. We also recommend checking out PlatformEngineering for upcoming community-driven events - both virtual and in-person.

The end goal of these sessions is to raise awareness around the importance of securing software packages throughout their lifecycle. That means not just scanning once, but maintaining ongoing vigilance through regular scanning, updates, and visibility into provenance. We know this can feel overwhelming, so our aim is to provide practical education, actionable best practices, and tooling insights to help you build safer pipelines with confidence. As long as security remains a moving target (and it always will), we’ll continue running these sessions to support the community.

Conclusion

Nearly everything deployed today in Kubernetes is through Helm Chart templates. If you need to deploy a security program into your cluster, most likely the security vendor you’re working with has a Helm Chart for that. So there’s an especially critical need to monitor and secure those third-party Helm charts that we consume as well. The questions raised during this session bring to light a common theme: many vulnerabilities don’t originate in Kubernetes itself, but in the way it's configured and operated. By applying security best practices, leveraging scanning and enforcement tools like Trivy and OPA, and maintaining a strong awareness of chart provenance and runtime behaviour, platform teams can seriously reduce risk.

Cloudsmith and PlatformEngineering.org remain committed to supporting the community with ongoing sessions like this, and by bringing clarity to the challenges of modern software supply chain security. Sign up today for our upcoming PlatformCon 2025 virtual workshop on Friday 27th, June. Watch this session in full on-demand, stay tuned for future events, and feel free to contact us anytime with questions about keeping your software artifacts secure.

helm

Open Container Initiative (OCI) Support in Cloudsmith

Responding to questions from our recent Helm security webinar

Getting Started with Helm and Cloudsmith

An Introduction to Helm