Vulnerabilities
The Vulnerabilities tab in Clusters → Observability lists the known CVEs in three places: the OS packages of every node, the cluster’s Kubernetes version, and the images running in the cluster. Each row says what fixes it. edka-agent reads the package lists and image SBOMs in the cluster and sends them to Edka, which matches them against public vulnerability data and matches them again when that data changes. Nothing scans inside the cluster.
Requirements
Section titled “Requirements”- Nodes: Debian 12 or 13, or Ubuntu 22.04, 24.04 or 26.04. This covers satellite clusters too. Hosts without the Debian package database show as not available.
- Kubernetes: every cluster. Edka reads the version each node’s kubelet reports.
- Images: an SBOM attestation in the registry. Images Edka builds carry one. Many public images do as well, for example the Docker Official Images. Images without one show in the Images section as having no SBOM.
Read the findings
Section titled “Read the findings”- Open Clusters → your cluster → Observability → Vulnerabilities.
- The strip at the top counts the CVEs by what fixes them: Fixed by a reboot, Fix not installed, No fix yet and Known exploited.
- Each section (Nodes, Kubernetes, Images) has one row per package and installed version. Where shows the nodes or images it is on.
- Click a row’s arrow to list its CVEs. Each CVE links to the Debian security tracker, Ubuntu’s CVE page or OSV, and shows its CVSS score, its EPSS score and the version that fixes it.
A node’s own findings are also on its Vulnerabilities tab in Explorer. The Nodes list shows a short summary under each node.
Status
Section titled “Status”| Status | Meaning | What fixes it |
|---|---|---|
| Reboot | The fixed version is installed, but the node still runs the old kernel or library. | A reboot. Use Update OS. |
| Not installed | A fixed version is available and not installed. | An OS update, a Kubernetes upgrade, or for an image, a rebuild with the fixed package. |
| Ubuntu Pro | The fix is only in Ubuntu Pro (ESM). | An Ubuntu Pro subscription on the node. |
| No fix | The distribution has no fixed version yet. | Nothing to install yet. The CVE moves to Not installed once a fix ships. |
| Unknown | The distribution has not triaged the CVE yet. | Nothing yet. |
A reboot fixes the kernel and the libraries already loaded at boot: libc6,
libssl3, openssl, systemd and dbus. For the kernel, Edka compares the
kernel the node runs with the newest one installed.
What the default view shows
Section titled “What the default view shows”Every CVE with a fix waiting, whatever its score. CVEs without a fix appear when one of these holds:
- it is in CISA’s Known Exploited Vulnerabilities catalog
- the distribution rates it high or critical
- its CVSS score is 7 or more, unless Debian marks it unimportant, no-dsa, postponed or ignored, or Ubuntu rates it negligible
Show all lists the rest. Kernel CVEs without a fix stay in one row per running kernel version.
Kubernetes
Section titled “Kubernetes”Rows in the Kubernetes section name the component (kube-apiserver,
kube-controller-manager, kubelet and so on) and the patch release that
fixes it. Upgrade opens the cluster settings where you
update the cluster. CVEs the Kubernetes project does
not fix by design, such as gitRepo volumes (CVE-2025-1767), show under
Show all only.
Notifications
Section titled “Notifications”- Known exploited vulnerabilities: a CVE in the KEV catalog has a fix waiting on a node, on the Kubernetes version or in an image.
- Critical fixes not installed: a fix for a CVE with CVSS 9 or more has waited more than three days on a node.
- Security fixes for Kubernetes: a Kubernetes patch release fixes a CVE in the cluster’s version.
- The pending reboot notification says how many CVEs the reboot fixes.
On a cluster with automatic OS updates, a known exploited CVE that an update or a reboot fixes starts a round in the next maintenance window without the usual one-day wait.
Data sources
Section titled “Data sources”The Debian security tracker, Ubuntu security data © Canonical Ltd. under CC BY-SA 4.0 (adapted), the Kubernetes CVE feed, the GitHub Advisory Database and OSV for image packages, NVD for CVSS scores, CISA KEV, and EPSS by FIRST.
Troubleshooting
Section titled “Troubleshooting”- A node shows “edka-agent has not read the package list yet”: the
edka-agent-nodeDaemonSet inedka-systemhas no ready pod on that node. Check it withkubectl -n edka-system get pods -o wide -l app.kubernetes.io/name=edka-agent-node. - An image Edka built shows no SBOM: it was built before Edka attached SBOMs. Rebuild it from the deployment.
- An image from a private registry has no SBOM listed: edka-agent reads
the SBOM with the pod’s
imagePullSecrets, then its ServiceAccount’s. Hover the note under Images to see the registry’s answer for each image.