[CNCF LFX Proposal] Kubescape External VEX Ingestion for Kubescape Vulnerability Scanning

### CNCF Project

Kubescape

### Term

2026 Term 3 (Sep-Nov)

### Program Name

External VEX Ingestion for Kubescape Vulnerability Scanning

### Program Description

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.

### Technologies

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

### Skills same as Technologies?

- [x] Yes, the required skills are the same as the technologies listed above.

### Required/Desirable Skills

_No response_

### Mentors

Matthias Bertschy | @matthyx | matthias.bertschy@gmail.com | matthyx
Ben Hirschberg | @slashben | ben@armosec.io | slashben

### Upstream Issue URL

https://github.com/kubescape/kubevuln/issues/387

### Application Prerequisites

- [ ] Resume
- [ ] Cover Letter
- [ ] School Enrollment Verification
- [ ] Participation Permission from school or employer
- [ ] Coding Challenge
- [ ] Custom Prerequisite (fill in details below)

### Coding Challenge URL

_No response_

### Custom Prerequisite Name

_No response_

### Custom Prerequisite Description

_No response_

### Custom Prerequisite — File Upload

- [ ] Yes — completion of this task requires the mentee to submit a file.

---
**LFX program:** [CNCF - Kubescape: External VEX Ingestion for Kubescape Vulnerability Scanning (2026 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/f83cb3c4-2acf-4f80-b734-83bbd43e0ffd)

Start by reading kubevuln's existing WatchHandler and CooldownQueue machinery, the OpenVulnerabilityExchangeContainer storage shape, and the scan pipeline point that produces a manifest per image. Map how external VEX sources could be fetched and joined with findings. Done means namespaced VEXSource support, validated persistence, suppression with provenance, feed deduplication, and an end-to-end test against a real CSAF or OpenVEX feed.

Written by the indexing model from the issue text.