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 --show-labels SBOMSPDXv2p3
NAME                                                               CREATED AT             LABELS
0349106521d476e8a833088c33f6db5ac4c898f00d1b6b6f15d9902ff5fdd0f4   2023-04-23T09:07:47Z
0f232ba18b63363e33f205d0242ef98324fb388434f8598c2fc8e967dca146bc   2023-04-23T09:04:23Z
1198b3b3f1e324799012d0634e96ef99e43831cdb240749f7ceaaab551b09622   2023-04-23T09:15:28Z
13964b29d63efcd1490d1a500c4332c642655fe4ca613683fa4dde9a205dd0f7   2023-04-23T09:14:05Z
1d20492ca374191e5b6ff4b7712b62b41ab75ce226424974356dc266e6e99e83   2023-04-23T09:04:06Z
20b172e673454b675cade099b95125fb1ce01b53fbf99c5b6260e048174060b1   2023-04-23T09:08:29Z

To view the filtered information:

% kubectl get -n kubescape --show-labels SBOMSPDXv2p3Filtered
NAME                                                               CREATED AT             LABELS
0207f7055a0a13a655efe073c320de83219ca19e396e37e1bdcc83de976ca99a   2023-04-23T10:05:48Z,,,,,
0d69953f27f65b0546fbd29b12849368cbc5a0cf358b828ee31fbe2865279dea   2023-04-23T10:06:07Z,,,,,
28372aa3a8dfdebb9cd2561f85beabbe58fbeb67060c3bde74a061c62923183f   2023-04-23T10:05:49Z,,,,,
30c70b40821cd009b417167b2280cd9d2df4e4eef8dff79f3c7f9a8ee7d75672   2023-04-23T10:05:42Z,,,,,


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.

The eBPF probes used by Kubescape do not report on the actual file when a symlink is opened, meaning relevant files opened by symlink may cause CVEs to appear as not relevant. This may result in false positives.