security(kubescape): the kubescape namespace is scanned by neither posture surface #3215

🤖 Generated by the Agentic Engineer

Evidence

The kubescape namespace is scanned by neither posture surface. Measured against admin@prod
on 2026-08-18 while verifying #3064:

• In-cluster scan: the operator's own kubescape/operator ConfigMap sets
  "excludeNamespaces": "kubescape,kube-system,kube-public,kube-node-lease,kubeconfig,gmp-system,gmp-public".
  Consistent with that, workloadconfigurationscans holds 0 objects whose
  kubescape.io/workload-namespace is kubescape — out of 1542 objects spanning 39
  namespaces. Not a stripped-LIST artifact: the unfiltered control returns 1542, and 65 Deployment
  scans exist for other namespaces.
• CI scan: ksail workload scan (ci.yaml) reads the repository's manifests. The four
  kubescape-operator Deployments exist there only as a HelmRelease, which is never rendered to
  Deployments, so they are absent from that surface too.

Problem

An entire namespace — the one running the security tooling itself — produces no posture measurement,
and nothing anywhere says so. This is the failure mode #2447 exists to prevent, in its most direct
form: absence is indistinguishable from compliance. Two concrete consequences already observed:

• security(kubescape): three Deployments genuinely fail C-0055 behind the blanket pod-security exception #3064 was written as "three Deployments genuinely fail C-0055 behind the blanket exception".
  The specs are indeed unhardened, but the exception is not what hides them — nothing scans them at
  all. The remediation was right; the diagnosis was not, and it could not have been checked against
  either surface.
• pod-security-mutations suppresses C-0013/C-0016/C-0055/C-0211 cluster-wide and is justified by a
  Kyverno mutation whose scope excludes ten namespaces (security: the cluster-wide pod-security exception suppresses controls where its own compensating control does not run #2824). For kubescape that justification is
  moot in a second, independent way: there is no scan result there for an exception to affect.

It also means a real regression in this namespace can never surface in the score, so the
"100% and hold" signal is silently narrower than it appears.

Expected

The gap is either closed or made explicit and measured — not left implicit. Options, in preference
order:

1. Scan the namespace: drop kubescape from the operator's excludeNamespaces and handle whatever
   surfaces (the self-scan exclusion looks like an upstream default rather than a deliberate local
   decision — confirm before changing).
2. If it must stay excluded, cover those workloads from the CI side by rendering the chart, so they
   are measured somewhere.
3. Failing both, record the uncovered namespaces as a first-class, asserted list, so "not scanned"
   is a visible state rather than a silent zero.

Whichever is chosen, the count of unscanned namespaces should be an assertion, so this cannot
regress unnoticed.

Acceptance criteria

• Every namespace that is excluded from posture scanning is enumerated somewhere a reader will
  encounter, with the reason it is excluded.
• The kubescape namespace's four Deployments are either scanned, or explicitly recorded as
  unscanned with that fact visible next to the compliance figure.
• A check fails if a namespace silently drops out of scan coverage.
• pod-security-mutations' rationale is corrected where it implies coverage that does not exist.

Size

Small-to-medium. Step 1 is a one-line config change plus whatever it surfaces; the durable half is
the assertion that stops coverage shrinking silently again.