Motivation

Many Helm charts in large monorepos are deployed via build systems that inject additional value files at deploy time (release names, datacenter config, OCI image references, etc.) that are not present in the chart's own values.yaml. The scanner cannot replicate that injection at scan time, so rendering those charts fails with Go template missing-value errors. This is a known, intentional limitation: full value resolution from build metadata would require parsing BAZEL files, which is out of scope given the complexity and narrow population of affected charts.

The consequence of these render failures was a severe log-level problem, not a loss of findings. When rendering fails the scanner falls back to scanning raw template files, which still detects and emits genuine security findings, the only degradation is that resource_name may contain an unresolved template expression rather than the concrete deployed name. Each render failure was producing 3–4 duplicate ERROR lines across independent pipeline layers, compounding further because each raw template file containing Go template syntax then produced an additional ERROR from the YAML parser. None of these logs carried information not already available at the outermost layer, and their volume made the ERROR logs noisy relative to failures that actually warrant attention.

Changes

Helm resolver

All Error() calls in runInstall and renderHelm are removed. Every failure path in those functions now returns the error silently. The resolverSink is the canonical signal for a chart render failure and now carries the full specific error message via errors.Wrap rather than the generic message that previously discarded the underlying cause.

Render-failure classification

resolverSink now distinguishes expected render failures (charts that reference deploy-time values absent at scan time, identified by well-known Go template missing-value error signatures) from unexpected ones. Expected failures log at Debug and register the chart directory as a known fallback; any other render failure stays at Error. The fallback announcement in resolveChartDir is similarly demoted to Debug since the render error is already logged by the layer below.

Raw template parse errors

Service tracks which chart directories failed to render. When the YAML parser fails on a file inside one of those directories, the expected outcome for raw Go templates, the error is logged at Debug. Parse failures on all other files remain at Error, preserving visibility into genuine parser bugs.

Author Checklist

• I have reviewed my own PR.
• I have added or updated relevant unit tests where necessary. If no tests are added, I've explained why.
• All new and existing tests pass.
• I have tested my changes on staging (if applicable).
• I have updated any relevant documentation (if applicable).

QA Instruction

1. go test ./pkg/runner/... ./pkg/resolver/helm/... ./pkg/engine/provider/...
2. Scan a Helm chart that requires deploy-time values and confirm: zero ERROR lines are emitted for that chart, the raw template files inside it produce no ERROR, and a single Debug line with the specific template error is present when debug logging is enabled.
3. Scan a non-Helm YAML file with intentionally invalid syntax and confirm the parse failure still surfaces at Error.

Impact

Only the Helm rendering and raw-template fallback path are affected. No scan results, rule logic, or output formats change, only log levels for known, handled failure conditions are reduced.

Additional Notes

I submit this contribution under the Apache-2.0 license.