Kubescape

Term 3 · Sep-Nov · 4 projects

• Agent Sandbox: CRD Posture Controls + gVisor Runtime Visibility

  LFX Mentorship · Listed in the official cohort

  @matthyxSource IssueLFX portal

  Google shipped GKE Agent Sandbox to GA and introduced Agent Substrate in May 2026, pushing agent security-relevant configuration into new object types (WorkerPool, ActorTemplate, sandbox resources) that live outside the workloads Kubescape scans today. An ActorTemplate decides whether model-generated code runs under gVisor/Kata or a shared kernel; a WorkerPool decides whether one runaway actor can starve every other session multiplexed onto it. Nothing currently treats these as posture decisions, even though the workload is untrusted by definition — the code an agent runs is generated by a model at request time, so the isolation and egress posture of the resource defining it *is* the trust boundary. This term combines two complementary halves of the same problem: static posture (cheap, ships day one) and runtime visibility (harder, the actual gap once isolation is misconfigured or bypassed). Part A — static posture and admission (near-term, PR #10 scope): - A new "Agent Runtime Hardening" Rego control framework against the WorkerPool / ActorTemplate / sandbox CRD schemas, covering: runtime isolation class pinned to gVisor/Kata (not shared-kernel default), default-deny egress with explicit allowlist, CPU/memory ceilings per actor, image provenance/registry allowlisting, per-session credential scoping, and encrypted/access-scoped snapshot storage. - Findings surfaced through the existing CLI, operator, and MCP-server paths, with framework mapping to OWASP LLM / MITRE ATLAS where controls map cleanly. - An admission-control variant (VAP or Kubescape admission) that rejects or warns on non-hardened ActorTemplate/sandbox definitions before they run. Part B — runtime visibility into gVisor sandboxes (stretch, this term's research contribution): - gVisor intercepts syscalls in userspace (the Sentry), so Kubescape's node-agent, which relies on kernel-level eBPF hooks, cannot see inside a gVisor-isolated actor the way it sees a normal container. This is the concrete visibility gap PR #10 explicitly defers. - Investigate and prototype a feasible signal source for gVisor-sandboxed actors without requiring in-Sentry code changes — candidates include runsc's built-in trace/strace export, Sentry-level seccomp/audit event forwarding, and host-visible boundary signals (network egress, process lifecycle of the Sentry process itself) — and feed whichever proves viable into the node-agent's existing event pipeline. - Deliver at minimum a design doc with a working proof-of-concept for one signal source (e.g. sandbox start/stop and network egress visibility), clearly scoped against what remains genuinely out of reach this term. Explicit non-goals: no per-session/per-actor runtime attribution, and no claim of full in-sandbox behavioral enforcement — this term establishes posture + admission plus a first, honest answer to the visibility question, not a complete gVisor introspection layer.

  • Go
  • OPA/Rego
  • Kubernetes admission control (ValidatingAdmissionPolicy)
  • eBPF
  • gVisor (runsc)

• Evidence of Finding: Path-Level Evidence in Scan Output

  LFX Mentorship · Listed in the official cohort

  @matthyxSource IssueLFX portal

  Kubescape reports that a control failed on a resource, but not *why*: which field triggered it, what value it held, or where in the source manifest to look. Users adopting Kubescape for audit and compliance work end up re-reading every flagged manifest by hand to validate each finding, and cannot distinguish a real failure from a false positive (e.g. control C-0012 firing on a Deployment that only uses valueFrom.secretKeyRef) without that context. This is the long-standing ask in kubescape/kubescape#1563 and the concrete complaint in kubescape/kubescape#1737 and kubescape/kubescape#1714. The underlying data already exists. Every Rego rule emits an AssistedRemediation block (FailedPaths, ReviewPaths, DeletePaths, FixPaths) alongside the full triggering Kubernetes object (AlertObject.K8SApiObjects) in opa-utils. A survey of the ~278 rules in regolibrary found 201 already emit at least one real evidence path; the gap is entirely on the presentation side — there is no renderer that resolves a path against the captured object, shows the offending value, maps it back to a source file/line, or redacts secrets before display. Deliverables for the term: - A path resolver that walks a JSON-path against the captured K8SApiObjects payload and returns the matched value. - A --show-evidence (-E) pretty-printer mode that renders, per failing resource, the matched path(s), resolved value(s), and — for file-based scans (raw YAML, Helm, Kustomize) — the originating file name and line number. - A redaction-by-default policy for evidence values, with an explicit --show-secrets opt-in, so evidence output is safe to share by default. - Test coverage against representative rules from each of the classified buckets (always-real paths, mixed, placeholder-only) to confirm the renderer degrades gracefully when no path-level evidence exists. - Documentation of the evidence contract for rule authors, so new regolibrary rules populate it correctly going forward. Stretch goals (time permitting): extending evidence rendering to the JSON and SARIF output formats, and live-cluster evidence pointers (kubectl command instead of file/line). This is a self-contained, mergeable slice of the full proposal in designs-and-proposals#4 — it does not require changes to regolibrary rule logic or the kubevuln pipeline, both of which are explicitly phased later.

  • Go
  • OPA/Rego
  • JSON
  • YAML
  • SARIF
  • Kubernetes

• External VEX Ingestion for Kubescape Vulnerability Scanning

  LFX Mentorship · Listed in the official cohort

  @matthyxSource IssueLFX portal

  Kubescape was the first open-source project to *produce* OpenVEX documents from its own scan results, but it does not *consume* VEX published by anyone else. Distribution base images (nginx, alpine, python, RHEL UBI) dominate CVE counts in most clusters, and vendors already triage most of those CVEs as not_affected or fixed — Red Hat publishes CSAF/VEX for every CVE touching its portfolio, and Chainguard publishes OpenVEX for Wolfi/Chainguard images. Grype, the scanner engine kubevuln already runs, can consume both formats via --vex. Kubescape's own pipeline currently ignores all of this, so users see dozens of CVEs their upstream vendor has already resolved or ruled out. The storage shape and pipeline hook already exist: kubevuln persists VEX as OpenVulnerabilityExchangeContainer objects today (for its own generated VEX), and the scan pipeline has a well-defined point where a manifest is produced per image. What's missing is (a) a way to declare and fetch external VEX feeds, and (b) a join step that applies vendor statements to suppress matching findings, with provenance preserved. Deliverables for the term: - A new namespaced VEXSource CRD declaring a feed URL, format (OpenVEX JSON or CSAF), applicable image scope, and refresh interval. - A controller (built on kubevuln's existing WatchHandler / CooldownQueue machinery) that fetches, validates, and persists external VEX documents into the existing OpenVulnerabilityExchangeContainer shape (or a clearly-scoped sibling kind). - A join step in the scan pipeline that matches external not_affected / fixed statements against scan results and suppresses matching findings before they reach a user, recording which document/statement caused each suppression. - Deduplication and normalization across feeds referencing the same CVE/image. - End-to-end tests against at least one real feed (Red Hat CSAF/VEX or Chainguard OpenVEX). This composes with — but does not require — the SecurityException CRD work; a vendor not_affected statement is functionally the same shape as a user-authored exception, so the design intentionally reuses that matching model. Authoring/editing VEX inside the cluster stays out of scope: this proposal is read-only ingestion of third-party data.

  • Go
  • Kubernetes controller-runtime/operators
  • OpenVEX
  • CSAF
  • Grype

• Native Multi-Cluster Fleet Posture Aggregation

  LFX Mentorship · Listed in the official cohort

  @matthyxSource IssueLFX portal

  Kubescape scans exactly one cluster per invocation, but almost every real user operates more than one (prod/staging/DR, per-region, per-tenant). Today there is no first-class way to ask fleet-wide questions like "which clusters fail control C-0016?" or "staging passes this control but prod fails it — where did we drift?". Users fall back to shell loops over KUBECONFIG plus hand-rolled jq merges, the commercial ARMO SaaS platform (excluding air-gapped/privacy-sensitive users), or bespoke CI glue — none of it shared or tested. Two things currently block this: there is no type above the single-cluster PostureReport anywhere in the codebase, and the Kubernetes client is a process-global singleton (kubescape/kubescape#2004), so even holding two live cluster clients at once is unsafe today. This proposal adds a kubescape scan fleet command that scans a list of kubeconfig contexts sequentially, through the existing, entirely unmodified single-cluster scan path — re-pointing the global client once per cluster and never holding two live clients at once — and aggregates the resulting PostureReports into a new, purely additive FleetReport type. Concurrency is explicitly deferred to a later phase gated on the #2004 singleton refactor, which keeps this term's scope small, self-contained, and mergeable without touching any existing report schema, printer, or public API. Deliverables for the term: - cmd/scan/fleet.go: new scan fleet subcommand accepting --contexts (comma-separated kubeconfig contexts) and --baseline, reusing existing scan flags. - core/pkg/fleet/orchestrator.go: sequential orchestrator that runs a complete, unmodified scan per context and collects per-cluster results. - A FleetReport type carrying a cross-cluster control matrix (control × cluster status) plus drift detection: controls whose result diverges from a chosen baseline cluster are flagged explicitly. - At least one printer for FleetReport (e.g. table or JSON) so results are usable from the CLI and in CI. - Tests covering multi-context orchestration, missing/unreachable contexts, and drift computation against a baseline. Open design questions the mentee will help resolve early in the term: where FleetReport should live in the module layout, and where OSS fleet aggregation stops versus where platform-level (SaaS) aggregation begins.

  • Go
  • Kubernetes client-go
  • CLI design

Term 2 · Jun-Aug · 2 projects

• CEL rule engine support and Rego-to-CEL control migration

  LFX Mentorship · Listed in the official cohort

  @matthyxSource IssueLFX portal

  Kubescape evaluates compliance controls using OPA/Rego today, while Kubernetes has shipped native ValidatingAdmissionPolicy / MutatingAdmissionPolicy resources that use CEL expressions. The kubescape/cel-admission-library project already ships a growing set of Kubescape controls as VAP resources, but Kubescape cannot evaluate them locally — so a resource passing kubescape scan may still fail the cluster's admission controller. This project adds a native CEL evaluation engine to Kubescape (running alongside Rego), using the same ValidatingAdmissionPolicy YAML format and google/cel-go library that Kubernetes uses internally. With the same rule expression evaluated in both places, Kubescape becomes directly comparable to — and competitive with — Kyverno for teams wanting a single policy language across CI, runtime scanning, and admission enforcement. A sample of existing Rego controls are then converted to CEL as proof-of-concept, validating the conversion pattern end-to-end.

  • Go
  • Kubernetes (CEL
  • ValidatingAdmissionPolicy
  • client-go)
  • familiarity with OPA/Rego a plus.

• In-cluster, GitOps-native SecurityException CRD for Kubescape, with Headlamp plugin support

  LFX Mentorship · Listed in the official cohort

  @matthyxSource IssueLFX portal

  Kubescape today has no declarative, in-cluster mechanism for posture/compliance exceptions — they only come from JSON files or the ARMO cloud API, which blocks GitOps-native workflows and air-gapped clusters. A design for a SecurityException / ClusterSecurityException CRD (group kubescape.io/v1) already exists and covers both vulnerability and posture exceptions in a single resource with OpenVEX-compatible fields, label/namespace/image selectors, CEL validation, and Kubernetes Events for observability. The kubevuln (vulnerability) side is being implemented by the maintainers; this project focuses on the kubescape (posture) side, the operator rescan integration, and surfacing exceptions in the Kubescape Headlamp plugin so users can view and manage them from the UI.

  • Go
  • Kubernetes (controllers
  • CRDs
  • client-go / controller-runtime
  • dynamic client)
  • TypeScript/React (for the Headlamp plugin).

Term 2 · Jun-Aug · 2 projects

• Advanced Kubescape plugin features for VSCode

  LFX Mentorship · Listed in the official cohort

  @slashbenSource IssueLFX portal

  Kubescape has a VSCode plugin to facilitate applying configuration fixes that harden Kubernetes infrastrcutture without creating a burden of context switching on engineers tasked with security scanning and implementing their results.

  • Javascript
  • some familiarity with the inner workings of the VSCode plugin system.

• Backstage plugin that adheres to the new plugin system

  LFX Mentorship · Listed in the official cohort

  @rotemamsaSource IssueLFX portal

  Backstage has become a popular option for an internal portal that provides information for engineers in different capacities. Creating a backstage plugin for Kubescape will ultimately help users achieve their goal of hardening Kubernetes clusters, by being able to view security posture information on Backstage and without context switching.

  • Typescript
  • React
  • some familiarity with new Backstage plugin system.

Term 3 · Sep-Nov · 2 projects

• Build an admission controller for Kubescape

  LFX Mentorship · Listed in the official cohort

  @craigboxSource IssueLFX portal

  Kubescape is a utility that can scan a Kubernetes cluster and report on its security posture. It can also scan individual workloads (e.g. YAML files) before they are applied. By creating a Kubescape admission controller, we will be able to combine the two, denying workloads into a cluster where it would reduce the security posture.

  • Go
  • Experience using Kubernetes and understanding of its concepts

• Upgrade the documentation publishing pipeline for Kubescape controls

  LFX Mentorship · Listed in the official cohort

  @slashbenSource IssueLFX portal

  Kubescape's control library includes more than 200 controls, tests that codify Kubernetes best practices derived from the most prevalent security frameworks in the industry. Metadata in the controls is used to generate documentation pages in the ARMO website. This project will update this automation to make this control documentation available on kubescape.io.

  • Python
  • Technical writing
  • Rego

Term 2 · Jun-Aug · 3 projects

• Prometheus exporter for image vulnerabilities

  LFX Mentorship · Listed in the official cohort

  @slashbenSource IssueLFX portal

  Kubescape has a component that runs in-cluster which performs image scanning on all the container images deployed to a cluster. This function is largely used to send the data to an external service. In this projet, you will develop a Prometheus exporter for the image vulnerability information produced by Kubescape. This will allow users to access the data from within the cluster, as well as use it for alerting.

  • Go
  • Prometheus

• Store Kubescape configuration scan results as CRs

  LFX Mentorship · Listed in the official cohort

  @slashbenSource IssueLFX portal

  Kubescape is a utility that can scan a Kubernetes cluster and report on its security posture. There is an "operator" which can be installed in the cluster to perform scheduled scans scan, but this is largely used to send the data to an external service. In this project, you will implement a mechanism in the Kubescape operator to save scan results locally in a custom resource (CR), as well as a watch so that scans can be performed on cluster state changes.

  • Go

• Vulnerability-based Dockerfile generator

  LFX Mentorship · Listed in the official cohort

  @slashbenSource IssueLFX portal

  Kubescape can detect vulnerabilities in a container image. Some can automatically be remediated by changing the base image version (or other package information) inside the Dockerfile which created the image. This project is to automate this remediation.

  • Go

Term 1 · Mar-May · 3 projects

• Build debugging capabilities for Helm

  LFX Mentorship · Listed in the official cohort

  @slashbenSource IssueLFX portal

  The Go standard templating package (text/template) is the base on which Helm templates are built. We wish to be able to backtrack lines and fields in objects after rendering Helm charts. This would help users of Helm to be able to understand quickly where different security issues in the final object are coming from in the source. To do this, the text/template package should be extended to include debug markers that point from the output lines to the input lines.

  • Go

• Implement security controls based on penetration testing best practices

  LFX Mentorship · Listed in the official cohort

  @slashbenSource IssueLFX portal

  Kubescape covers different hardening guidelines around Kubernetes: NSA-CISA, MITRE and CIS. Detection capabilities of potential security issues could be even more enriched by researching pen-testing tools and practices regarding Kubernetes and implementing these as controls. An example pen-test writeup is This and others could help define a set of “offensive” controls to complement the “defensive” controls we have today.

  • Cybersecurity
  • Rego

• Release engineering: add Kubescape to commonly-requested package managers

  LFX Mentorship · Listed in the official cohort

  @craigboxSource IssueLFX portal

  The Kubescape client binary is built from GitHub using standard patterns. Support for homebrew and krew exists, but users have requested RPM and DEB packages. In this project you will stabilize the delivery of new builds to existing package managers, and implement support for RPM and DEB packages using GitHub Actions.

  • Release management
  • scripting