- 108comments
- 136comments
- 96comments
- 76comments
- 23comments
- 445comments
- 76comments
- 63comments
- 285comments
- 20comments
- 340comments
- 40comments
- 82comments
- 16comments
- 32comments
- 92comments
- 6comments
- 4comments
- 1comments
- 106comments
- 1comments
- 269comments
- 89comments
- 4comments
- 73comments
- 1comments
- 14comments
- 76comments
- 100comments
- 24comments
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.