bug: host namespace flags are ignored inside security contexts

[1PoPTRoN]

What happened?

optiqor analyze can miss host namespace findings when hostNetwork, hostPID, or hostIPC are nested under a security-context-style values map.

Expected: nested host namespace fields should populate parser.Workload.Security so the existing host-network, host-pid, and host-ipc detectors can fire.

Actual: the parser only reads these fields from the workload-level mapping, so nested values are silently ignored.

Reproduction steps

1. Create a values file containing the YAML fragment below.
2. Run `optiqor analyze ./values.yaml --detector host-pid --detector host-ipc --detector host-network`.
3. Notice no host namespace findings are emitted, even though the workload sets host namespace flags under `podSecurityContext`.

optiqor-cli version

2e997fc

Install method

Built from source

OS and arch

macOS 15.7.7 / arm64

Relevant output

No `host-network`, `host-pid`, or `host-ipc` findings are emitted for the nested values shape.

Minimal chart fragment (if applicable)

agent:
  resources:
    requests:
      cpu: 50m
  podSecurityContext:
    hostNetwork: true
    hostPID: true
    hostIPC: true

Additional context

This appears to be in pkg/parser/helm.go.

readSecurity reads hostNetwork, hostPID, and hostIPC from the workload-level map. Nested securityContext, podSecurityContext, and containerSecurityContext maps are handled by applySecFields, but that helper does not currently copy the host namespace fields.

The detectors themselves already behave correctly when parser.Workload.Security.HostNetwork, HostPID, or HostIPC are populated, so this looks like a parser false negative.

[github-actions]

Welcome to optiqor-cli, and thanks for opening your first issue!

A maintainer will triage this within 48 hours. While you wait:

• Read CONTRIBUTING.md if you'd like to send a fix
• Try it on your own chart: npx @optiqor/cli analyze ./your-helm-chart
• Discussions for questions and design talk

Tip: if you can paste the output of optiqor analyze --debug ./your-chart (or a minimal chart fragment that reproduces) we'll diagnose 90% faster.

[Ranjithhub08]

Confirmed. The fix is a one-liner in applySecFields — add the same host namespace loop that readSecurity already has at the top level:
gofunc applySecFields(ctx *yaml.Node, out *SecurityContext) {
// ADD: host namespace fields when nested under podSecurityContext
for _, key := range [][2]string{
{"hostNetwork", "HostNetwork"},
{"hostPID", "HostPID"},
{"hostIPC", "HostIPC"},
} {
if v := findChild(ctx, key[0]); v != nil && v.Kind == yaml.ScalarNode {
b := boolValue(v.Value)
switch key[1] {
case "HostNetwork":
out.HostNetwork = &b
case "HostPID":
out.HostPID = &b
case "HostIPC":
out.HostIPC = &b
}
}
}
// existing fields follow...
One thing to note: if both the workload-level map and podSecurityContext declare the same field with conflicting values, the nested value will win (last write). Worth deciding whether workload-level should take precedence — the current readSecurity loop over security context keys runs after the top-level host namespace read, so nested would currently override top-level. Happy to send a PR if the approach looks right.

[Ranjithhub08]

Hi, I'd like to take this one if it's available. I've traced the root cause to applySecFields in pkg/parser/helm.go — it handles securityContext/podSecurityContext/containerSecurityContext but doesn't copy hostNetwork, hostPID, or hostIPC from those nested maps, while readSecurity only reads them from the workload-level map. The fix is straightforward and the existing detectors + tests should cover it once the parser populates the fields correctly. I'll submit a PR with a test case for the nested values shape.