Kustomize foundations: model, bounded filesystem, Helm renderer

[whitemerch]

Tip

This PR is best reviewed commit by commit.

Summary

• Refactor Helm chart rendering into a reusable preprocessor renderer with virtual file outputs and option handling.
• Add Kustomize foundation model/provenance types plus shared YAML line detection support for future resolver work.
• Add bounded filesystem safeguards for resolver file access and wire virtual files through scan preparation

Full design context and architecture details: #113

Test plan

• go test ./cmd/scanner ./pkg/featureflags ./pkg/kics ./pkg/resolver/helm ./pkg/resolver/sandbox ./pkg/scanner
• git diff --check origin/main

Non-goals

• No Kustomize preprocessor is registered or enabled in this PR.
• Existing Helm scan behavior is expected to remain compatible for the default scanner path.

[datadog-datadog-prod-us1]

🎯 Code Coverage (details)
• Patch Coverage: 55.25%
• Overall Coverage: 45.52% (+0.08%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 79096eb | Docs | Datadog PR Page | Give us feedback!}

[MikaYuoadas]

This PR is very big, its sheer size overflow the context of my limited brainpower (there’s only so much token available before my brains gives up 😆 ).
But I’ve done my best to read it all and left a few comments on minor issues I found.

Otherwise the main thing I’m concerned about is not in the code itself but on the decision to surface resolver failure as vulnerability that IIUC will be added to the final SARIF output and will create customer facing findings. Is that intended design? I find it quite strange, and if we want to do so it may warrant more product discussion. We are a security product, not a linter for syntax error. IMHO findings about syntax error is not something customers expect to see in IaC explorer. (but correct me if I understood it wrong).

[whitemerch]

This PR is very big, its sheer size overflow the context of my limited brainpower (there’s only so much token available before my brains gives up 😆 ). But I’ve done my best to read it all and left a few comments on minor issues I found.

Otherwise the main thing I’m concerned about is not in the code itself but on the decision to surface resolver failure as vulnerability that IIUC will be added to the final SARIF output and will create customer facing findings. Is that intended design? I find it quite strange, and if we want to do so it may warrant more product discussion. We are a security product, not a linter for syntax error. IMHO findings about syntax error is not something customers expect to see in IaC explorer. (but correct me if I understood it wrong).

@MikaYuoadas Nop, you are totally right. I misunderstood this part of the code, I needed a way to report non-fatal resolver problems while still continuing the scan, but I will mimick the Helm behavior for now