From 51d2ea104a0e4e4e0600f014e459d21536715b1d Mon Sep 17 00:00:00 2001 From: Nikolai Emil Damm Date: Thu, 17 Sep 2026 22:22:22 +0200 Subject: [PATCH 1/2] fix(security): pin the Kubescape relevancy capability instead of inheriting it Relevancy scanning feeds the reachable-CVE gate, but it was enabled only by chart 1.40.4's default. Declaring it makes a future default flip a visible, reviewable change rather than a silent loss of a security capability. Verified: chart 1.40.4 defaults relevancy=enable, so the rendered ks-capabilities ConfigMap is byte-identical with and without this pin; an ablation setting relevancy=disable does change it, confirming the render is sensitive to the value rather than ignoring it. Fixes #3707 Co-Authored-By: Claude Opus 5 (1M context) --- .../controllers/kubescape/helm-release.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/k8s/bases/infrastructure/controllers/kubescape/helm-release.yaml b/k8s/bases/infrastructure/controllers/kubescape/helm-release.yaml index 74d57b5af..39025568f 100644 --- a/k8s/bases/infrastructure/controllers/kubescape/helm-release.yaml +++ b/k8s/bases/infrastructure/controllers/kubescape/helm-release.yaml @@ -53,6 +53,14 @@ spec: # posture silently ages (observed live 2026-08-28, issue #3275). continuousScan: enable vulnerabilityScan: enable + # Pinned rather than inherited. Chart 1.40.4 already defaults this to `enable`, so + # this changes nothing today — it is here so a future chart default flipping to + # `disable` cannot silently switch a security capability off. Relevancy is what makes + # the ApplicationProfile/VEX verdicts above meaningful: the eBPF node agent observes + # which libraries a container actually loads, so kubevuln can mark unreachable CVEs + # not_affected. Verified live 2026-09-17: ks-capabilities reads relevancy=enable, with + # 1133 vulnerabilitymanifests labelled kubescape.io/context: filtered vs 235 non-filtered. + relevancy: enable # kubevuln emits an OpenVEX document per scanned image (stored in-cluster # as OpenVulnerabilityExchangeContainer CRs), marking CVEs not_affected # when the workload's ApplicationProfile shows the vulnerable component From edee95c3b697d1c88cb05702ae5f1fb0fd29c616 Mon Sep 17 00:00:00 2001 From: Nikolai Emil Damm Date: Fri, 18 Sep 2026 00:17:55 +0200 Subject: [PATCH 2/2] fix(security): re-approve the authorization fingerprint for the relevancy pin Pinning the Kubescape relevancy capability moves the rendered authorization surface because a HelmRelease is a controller-RBAC emitter, even though the single added values line grants nothing. Conservation against main eea5453d: 573 identities per side with identical sorted lists, exactly one differing rendered document (the kubescape HelmRelease), and 94 grant-bearing documents hashing byte-identically. Both results are controlled by a synthetic ClusterRole that changes each. Co-Authored-By: Claude Opus 5 (1M context) --- scripts/validate-eks-ci-role-policy/main.go | 30 +++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/scripts/validate-eks-ci-role-policy/main.go b/scripts/validate-eks-ci-role-policy/main.go index a3360c360..06f0286aa 100644 --- a/scripts/validate-eks-ci-role-policy/main.go +++ b/scripts/validate-eks-ci-role-policy/main.go @@ -2602,7 +2602,33 @@ const ( // digest is claimed. // // Previous aggregate: 1ef7baab087081f6145391fe81e52d5ec712edec311e6c56009318509faa8d46. -const expectedRenderedSurfaceSHA = "a4781e58fb84590c887d65a6672e2d4857965c5b2ce998b5729c41ecc6c9fba6" +// +// Moved again by pinning the Kubescape relevancy capability (#3707). The +// kubescape HelmRelease gains one values line, relevancy: enable, which the +// chart already defaults to; a HelmRelease is a controller-RBAC emitter, so +// this moves the aggregate even though nothing is granted and no rendered +// behaviour changes. +// +// CONSERVATION: rendering all five authorization overlays on this branch and on +// main eea5453d yields 573 identities per side with an identical sorted identity +// list. Exactly one rendered document differs between the two sides, and it is +// the kubescape HelmRelease, whose whole delta is the single added values line. +// The 94 grant-bearing ClusterRole, Role, ClusterRoleBinding, RoleBinding and +// ServiceAccount documents hash byte-identically on both sides (fac77cff); +// appending one synthetic ClusterRole to the branch render changes that hash and +// adds an identity to the sorted list, so both identical results are findings +// rather than blind reads. No identity, binding, ServiceAccount, verb, wildcard, +// AWS identity or permission changes. +// +// RENDERER PROVENANCE: the value below was read from CI's own failure on job +// 105399991022 for head 75a0308e (this branch, on CI run 35279942247), which +// renders under the approved SHA256-verified kubectl v1.36.2; the job's single +// failing test was this unapproved aggregate. This host's kubectl renderer is +// unapproved, so it was used only for the conservation comparison and no local +// digest is claimed. +// +// Previous aggregate: a4781e58fb84590c887d65a6672e2d4857965c5b2ce998b5729c41ecc6c9fba6. +const expectedRenderedSurfaceSHA = "f6e7e761ab655cf26aace0e8f0e5df6ee469ebc012c047148cba322c01ef3cd3" // previousRenderedSurfaceSHA is the aggregate the approval above supersedes, in // machine-readable form. It is the base the approval was computed against. @@ -2615,7 +2641,7 @@ const expectedRenderedSurfaceSHA = "a4781e58fb84590c887d65a6672e2d4857965c5b2ce9 // review as a plausible-looking constant. A change that does not move the // surface leaves both constants untouched. Reverting a re-approval is itself a // re-approval: restore the older aggregate and record the current one here. -const previousRenderedSurfaceSHA = "1ef7baab087081f6145391fe81e52d5ec712edec311e6c56009318509faa8d46" +const previousRenderedSurfaceSHA = "a4781e58fb84590c887d65a6672e2d4857965c5b2ce998b5729c41ecc6c9fba6" // authorizationOverlayPaths lists every independently reconciled production // layer where an object can grant privileges to the aws/aws service account.