Closed slashben closed 12 months ago
This is wonderful, please let us know if @openvex can help!
@matthyx added support in Kubevuln PR #179 but it covers only creation and update. Where should we handle the cleanup of objects?
@matthyx added support in Kubevuln PR #179 but it covers only creation and update. Where should we handle the cleanup of objects?
In the operator, check with @vladklokun
Released! 💯 🚀
For the reference see here initial doc: https://kubescape.io/docs/operator/generating-vex/
Overview
Kubescape calculates the relevancy of container image vulnerabilities by monitoring using eBPF the application behavior and produces a filtered list of vulnerabilities. Today the results are stored in the same format as the vulnerabilities, however the VEX seems to be a much better choice to store and publish this information. Kubescape needs to publish the filtered list of vulnerabilities in a VEX format.
Solution
In the current state, the Kubevuln is watching the filtered SBOM objects, every time a new object is created or updated a filtered SBOM is created by the node-agent with only those modules that were loaded into the memory.
When a new filtered SBOM is available, the Kubevuln translates the SBOM to vulnerability list using Grype to create a filtered vulnerability list.
In the same step when the filtered vulnerability is created, Kubevuln should generate a VEX object. The object contains statements that all these vulnerabilities are loaded into the memory therefore they're relevant. This object should be stored as an API objects another vulnerability related.
See more at here
cc: @craigbox @puerco