HelmGuard — catching bad Helm charts before they reach a cluster

Render the chart, then analyse what actually comes out. The scanner downloads and extracts the chart, locates the chart directory, recursively merges the supplied values over the defaults, and renders the templates the way Helm itself would. Everything after that point operates on the resulting Kubernetes manifests rather than on the templates that produced them. This distinction is the whole design: static analysis of template source has to reason about branches that may never be taken and values that may be overridden, so it is simultaneously prone to false alarms and to missing the thing that actually ships. Rendering first collapses all of that uncertainty — what the analyser sees is what the cluster would get.

Resource prediction, so you know what you are about to create. Before any security judgement is made, HelmGuard reports the inventory: every Kubernetes resource the chart will create, with its kind, name, and namespace, plus the details that matter per type — the ports a Service will expose, the hosts an Ingress will claim, the size a PersistentVolumeClaim will request, how many keys a Secret or ConfigMap holds. This alone answers the question people usually resort to `--dry-run` for, and it is frequently where the surprises are: a chart that turns out to create a LoadBalancer, or claim a hostname, or provision storage nobody expected to be paying for.

A security rule set aimed at the failures that actually happen. Eight security rules run against the rendered output, each with a stable identifier, a category, a severity, and a specific remediation rather than just a complaint. They cover containers running as root, privileged mode, missing CPU and memory limits, images pinned to `latest` or left untagged, absent NetworkPolicies, writable root filesystems, containers that never drop Linux capabilities, and hardcoded credentials in templates. These are grouped under Security Context, Resource Management, Image Security, and Network Security, and graded critical through medium — because a privileged container and a missing NetworkPolicy are not the same conversation, and a tool that presents them as equals gets ignored.

Deliberate effort to keep false positives down. A scanner that cries wolf is worse than no scanner, because teams learn to skim past it. Credential detection in particular is a minefield: the string `password` appears constantly in field names, placeholder values, and template variables that resolve to a Secret reference rather than a literal. So the analysis includes explicit handling for likely false positives, separate logic for genuinely hardcoded credentials versus references, and a check for empty password fields as its own distinct case. That work is invisible when it succeeds, and it is the difference between a report people act on and one they dismiss.

Best-practice scoring across four dimensions, reporting what passed as well as what failed. Beyond the security rules, thirty best-practice checks run across four categories: Security, Reliability, Performance, and Maintainability. Reliability asks whether health checks are configured, whether replicas and pod disruption budgets exist, whether shutdown is graceful and updates roll. Performance looks at autoscaling, resource optimisation, and quotas. Maintainability covers documentation, naming conventions, version pinning, and template hygiene. Critically, the report lists the practices a chart follows alongside the ones it violates — partly because that is more useful for judging an unfamiliar third-party chart than a bare list of complaints, and partly because a wall of failures with no acknowledgement of what was done right is how tools lose their audience.

A REST API and a web UI, with GitHub OAuth for private charts. The Go backend is organised into clear internal packages for configuration, GitHub integration, chart scanning, and the HTTP server, and exposes a small REST surface: submit a public chart for scanning, submit a private one, and retrieve results by scan ID once the analysis completes. Private repositories are handled through a full GitHub OAuth flow — the user authorises, the backend lists their repositories, and they select the chart to scan, so nothing has to be made public in order to be checked. The TypeScript frontend renders the findings, which matters more than it sounds: chart review is often done by someone other than the chart's author, and a browsable report meets them where they are instead of assuming a terminal and a JSON parser.

No cluster, no credentials, no execution. Scanning happens entirely in a temporary working directory. HelmGuard never needs kubeconfig access, never authenticates to a cluster, and never installs anything — which means it is safe to point at an untrusted third-party chart, precisely the case where you most want to know what is inside before finding out the hard way. It also means the tool can sit early in a workflow, at review time, rather than late, at admission time, when the only remaining options are to accept the risk or roll back.