If you run hardened containers (readOnlyRootFilesystem, runAsNonRoot, resource limits, etc.), you've probably noticed that trivy/grype still flag CVEs that aren't actually exploitable in your environment.
There's no standard way to say "this CVE doesn't apply to my deployment." vex8s bridges that gap. It uses an embedded ML model to classify each CVE by exploitation type (arbitrary file write, privilege escalation, resource exhaustion, etc.), then checks your Kubernetes manifest to determine if the settings already mitigate it. The output is an OpenVEX document that scanners like trivy can consume to suppress those CVEs.
Example: a CVE classified as arbitrary_file_write gets suppressed if your container has readOnlyRootFilesystem: true with all volume mounts set to read-only.
If you run hardened containers (readOnlyRootFilesystem, runAsNonRoot, resource limits, etc.), you've probably noticed that trivy/grype still flag CVEs that aren't actually exploitable in your environment. There's no standard way to say "this CVE doesn't apply to my deployment." vex8s bridges that gap. It uses an embedded ML model to classify each CVE by exploitation type (arbitrary file write, privilege escalation, resource exhaustion, etc.), then checks your Kubernetes manifest to determine if the settings already mitigate it. The output is an OpenVEX document that scanners like trivy can consume to suppress those CVEs. Example: a CVE classified as arbitrary_file_write gets suppressed if your container has readOnlyRootFilesystem: true with all volume mounts set to read-only.
Paper with the full research: https://github.com/alegrey91/vex8s/blob/main/docs/environmet...
Would love feedback :)