Add Kubernetes privileged workload matcher

[jadenfix]

What changed

Adds and registers a reusable k8s-privileged-workload matcher for privileged execution, host access, root UID, unmasked proc mounts, and dangerous Linux capabilities.

The matcher now:

• limits findings to recognized Kubernetes workload documents and their real top-level spec
• handles multi-document YAML while preserving global line numbers
• detects inline and block-list dangerous capabilities under capabilities.add
• scans first-party Helm charts
• ignores ConfigMaps, capabilities.drop, annotations, and YAML-looking block-scalar data

Why

DeepSec already reviews Kubernetes secret handling but had no built-in workload privilege coverage. Document and spec scoping keeps this high-value rule in the precise noise tier instead of flagging configuration text that only resembles a workload setting.

Verification

• pnpm --filter @deepsec/scanner build passes
• 1,859 scanner matcher and matcher-example tests pass
• Biome passes on the changed TypeScript files
• git diff --check passes
• Adversarial cases cover Helm paths, block capabilities, mixed YAML documents, ConfigMaps, dropped capabilities, block scalars, and source line preservation

Notes for reviewer

Generated dependencies and workflow paths remain excluded; first-party charts/**/templates manifests are intentionally scanned. The branch is based on the current main.

[vercel]

@jadenfix is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[jadenfix]

Ready for review at e1c02cd. The scanner package builds, all 1,859 matcher and matcher-example tests pass, Biome passes on the changed TypeScript, and git diff --check is clean. Adversarial coverage now includes first-party Helm charts, block-list capabilities, mixed YAML documents, ConfigMaps, dropped capabilities, annotations, block scalars, and exact source lines. GitHub Actions remain action_required for this fork, and Vercel previews require Vercel Labs authorization; an upstream maintainer must approve those service gates.

[lokesh0186]

I independently exercised the privileged-container portion of this matcher with IaC-Guard-V 0.1.0a1 against the current PR head (783195c…) and found one reproducible false negative:

securityContext: {privileged: true}

The equivalent block form is detected by the matcher, but this inline-map form produces no DeepSec finding. IaC-Guard-V’s protected kubernetes_no_privileged_containers_v1 oracle classifies the exact Pod resource as FAIL / ASSERTION_VIOLATED, consistent with Kubernetes Pod Security Standards.

I also found two additional boundary cases that may be useful depending on the intended matcher scope: a top-level kind: List containing a privileged Pod, and Windows hostProcess: true.

Minimal fixtures, exact SHAs, reproduction steps, and sanitized results are here:
https://github.com/lokesh0186/iac-guard-v/tree/556b0f29262ec149dafb30a3c1d9de8bb1c22b6c/examples/public-reproductions/vercel-labs-deepsec-112