Vex8s suppresses non-exploitable container CVEs using Kubernetes security contexts

An experimental open-source tool called vex8s, surfaced on Hacker News's front page, takes aim at container vulnerability noise. It generates VEX (Vulnerability Exploitability eXchange) documents by cross-referencing CVEs found in container images with the Kubernetes settings a workload actually runs under, so that findings the configuration already neutralises can be hidden from later scans. The project lives on GitHub under the handle alegrey91, and its README states plainly that the work is experimental and that details are likely to keep moving.

How the exploitability check works

According to the project's documentation, vex8s builds its verdict through a multi-step pipeline. Each CVE is first categorised into one or more weakness classes (CWEs). The CVE's description is then processed by a machine-learning model that predicts an exploitation category for it. Those CWE assignments and predicted categories are combined to decide whether the CVE can be mitigated through configuration, and each exploitation category maps to a set of Kubernetes settings that can prevent or blunt that class of attack.

The tool then parses a Kubernetes manifest and inspects the container's configuration, notably the securityContext, to see whether the relevant options are in place. Combining the two analyses yields a judgement on whether a CVE is exploitable in that particular workload, and any mitigated CVE is written into the final VEX document as suppressed. For readers who want the underlying reasoning, the project links to a paper titled "Environment-Aware Vulnerability Suppression Using Kubernetes Security Contexts and VEX".

The practical shift is that a CVE is no longer treated as universally dangerous. In principle, a vulnerability whose attack path depends on privileges a pod never grants could be marked not exploitable for that deployment, even if it would still matter elsewhere.

Passive and active modes

Two workflows are supported. In passive mode, which the project recommends, you hand vex8s an existing vulnerability report produced by Trivy or Grype along with your Kubernetes manifest, and it generates the VEX document. You then re-run the scan with the scanner's VEX flag — for example trivy image --vex nginx.vex., optionally with --show-suppressed to keep visibility into what was filtered. An equivalent flow is documented for Grype, anchored on its CycloneDX SBOM output.

Active mode removes the manual report step: vex8s calls the Trivy or Grype engine itself against the image and builds the VEX document directly from those results.

Classifier options: offline model or Gemini

The classification step has two engines, selected with the --classifier flag. The default is an ONNX machine-learning model embedded in the binary that runs without any network access, a useful property for air-gapped or restricted environments. The alternative sends the CVE description to Google's Gemini LLM, which requires a GEMINI_API_KEY environment variable, with an optional GEMINI_MODEL override. The project also credits Akihiro Suda's earlier vexllm project as its inspiration.

Why it matters

Container scanners are thorough by design, and the cost is alert fatigue: long lists of CVEs shipped in base images, most of which will never be exploitable in any given deployment. VEX exists precisely so that "not affected" statements can be recorded and consumed by downstream tools, but producing those statements has largely been manual work. Vex8s automates a slice of it using information that already exists in every cluster: the workload's own configuration.

The caveats are real. The verdict depends on the manifest supplied, so drift between what is declared and what is actually running — admission-controller mutations, injected sidecars, manual overrides — could produce a false "not exploitable". An ML classifier predicting exploitation categories will also get some cases wrong, and the project itself labels the work experimental. Viewed as a proof of direction rather than a production gate, however, it points at something valuable: vulnerability triage that accounts for the environment, not just the package list. The traction on Hacker News suggests plenty of operators recognise the problem it is trying to solve.