3 ms·
This is very cool, why not directly test the exploitability direct with harmless pods on the cluster for verification? If it's only model based as a defender I'
by Grimburger 8d ago
This is very cool, why not directly test the exploitability direct with harmless pods on the cluster for verification? If it's only model based as a defender I'd worry about how many % of misses arise. Even frontier models are going to miss some stuff, a programmatic gate seems prudent.
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.
- iou 7d agoBefore LLMs “just-patch-anyway” was a viable strategy because of the low volume. Now it’s amplified so much that taking that approach can introduce instability when the vulnerability was not even exploitable in your usage. 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.
- alegrey91 7d agoLet me know what do you think in case you decide to use it. The model is still far from being perfect, but it gives decent results considering I'm new to the ML topic.
- alegrey91 7d agoHello, thanks for your feedback. The point of vex8s is to avoid fixing all the CVEs at the same time giving them less or more priority depending on their exposure. If you find there's some protection, you can keep that CVE aside to focus more on other with higher priority.