The idea is to distinguish vulnerabilities that are actually exploitable in a given deployment from those mitigated by Kubernetes security settings (for example, readOnlyRootFilesystem, dropped capabilities, non-root users, and read-only volume mounts).
vex8s embeds a ML model trained on CVE data to predict vulnerability classes, then combines those predictions with the workload's security configuration to determine whether a vulnerability can be mitigated.
I'm particularly interested in feedback on the decision logic and on whether this approach could be useful as part of a vulnerability scanning pipeline.
Not trying to be negative, do think it's a good approach youve got, but the modern reality of dealing with cve's and compliance is to just fix them because it's a massive headache trying to write exemptions for all the ones that don't matter. Been my experience anyway.
Take the recent example of Copy/Fail (CVE-2026-31431) if you were to evaluate it against your k8s seccomp and noticed that the argument to the syscall socket of AF_ALG is not allowed, then the vuln is not reachable in your pods.
I’ve not used this tool (I plan to check it out), but I think contextual evaluation of CVEs is important in modern times.