- 27comments
- 137comments
- 285comments
- 31comments
- 101comments
- 487comments
- 87comments
- 134comments
- 3comments
- 11comments
- 294comments
- 349comments
- 1comments
- 19comments
- 3comments
- 20comments
- 85comments
- 43comments
- 100comments
- 41comments
- 4comments
- 6comments
- 112comments
- 273comments
- 5comments
- 89comments
- 75comments
- 2comments
- 92comments
- 15comments
vex8s is an open source tool that analyzes Kubernetes workloads and generates VEX documents based on their SecurityContext.
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.
GitHub: https://github.com/alegrey91/vex8s
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.