Skip to content

Vulnerability relevancy

The relevancy feature of the Kubescape operator enables users to understand which vulnerabilities detected by the vulnerability scanner are likely to be relevant, based on evaluation at runtime.

Kubescape's relevancy filtering is implemented by an eBPF program on each node, deployed using the node agent. It scans the running environment and maps out artifacts and libraries that are loaded into memory and therefore are in use in the environment.

Using eBPF probes, it looks at the file activity of a running container. When a pod starts on a node, the node agent will watch its containers for a configurable learning period and store an activity log.

During the process of scanning a container, an SBOM is generated. This contains the vulnerability scanner’s understanding of which components are installed in the container. When vulnerabilities are checked, the engine is provided with a filtered SBOM, including the packages that relate to files that were accessed during the learning period.

Enabling relevancy

Relevancy is installed by default when installing the Kubescape operator through Helm. You must have a node that supports eBPF.


Relevancy does not work on Minikube or Docker Desktop.

The durations for how long the node agent will observe a running container are configured with the nodeAgent.config values in the Helm installation:

    maxLearningPeriod: 3h 
    learningPeriod: 2m
    updatePeriod: 10m

Using the Relevancy feature

After installation, the node agent will start listening for every new or restarted container for the time configured in the learning period. Once the learning period concludes, the relevancy information will be available in the in-cluster storage and sent to a configured provider. The node agent will keep listening for the container until the maxLearningPeriod is reached.

View relevancy information

Counts of relevant vulnerabilties are available in the vulnerability summary objects. The vulnerability manifest will show whether a given CVE was found relevant or not.

The full and filtered SBOM objects are stored in the kubescape namespace. View the labels to get the information as to which image and parent object the SBOM relates to.

% kubectl get -n kubescape sbomsyfts
NAME                                                                                                                                              CREATED AT                                           2024-02-13T09:14:25Z                                          2024-02-13T09:15:02Z                                            2024-02-13T09:14:30Z                                        2024-02-13T09:14:55Z                                                                                              2024-02-13T09:11:47Z                              2024-02-13T09:11:03Z                                                                                     2024-02-13T09:13:02Z             2024-02-13T09:12:40Z                  2024-02-13T09:11:11Z                                          2024-02-13T09:12:35Z                   2024-02-13T09:12:01Z

To view the filtered information:

% kubectl get -n kubescape sbomsyftfiltereds
NAME                                                             CREATED AT
job-kubescape-scheduler-28465179-kubescape-scheduler-ebc9-3511   2024-02-14T11:39:13Z
job-kubevuln-scheduler-28464136-kubevuln-scheduler-c7f6-7f3d     2024-02-13T18:16:10Z
replicaset-collection-94c495554-alpine-container-a3d8-540c       2024-02-13T09:16:22Z
replicaset-collection-94c495554-redis-6eab-b388                  2024-02-13T09:16:22Z
replicaset-collection-94c495554-wordpress-94fd-4e76              2024-02-13T09:16:23Z
replicaset-storage-745bb58996-apiserver-a381-b389                2024-02-13T09:12:37Z


Linux kernel

The relevancy functionality is based on eBPF, which is currently only implemented on Linux. This feature will not work on Windows. The kernel version on the node must be >= 4.14.


The node agent uses the Inspektor Gadget library.