Ваша версия сопоставляется с машиночитаемыми диапазонами версий, публикуемыми вместе с каждым GitHub Security Advisory и доступными через OSV. Это принципиально: официальный CVE-фид Kubernetes описывает затронутые версии только текстом, и сопоставление по тексту давало бы ложноотрицательные ответы — ошибку, которую инструмент по уязвимостям допускать не должен.
По каждому адвизори показывается исправление в вашей линии релизов. Kubernetes бэкпортит каждый фикс во все поддерживаемые минорные версии, поэтому кластеру 1.28 нужен патч 1.28, а не релиз 1.31, который тоже указан в адвизори.
Какие компоненты покрыты?
Ядро Kubernetes, публикуемое как k8s.io/kubernetes. Адвизори экосистемы вокруг него — ingress-контроллеры, CSI-драйверы, операторы — заводятся в их собственных проектах и в этот набор данных не входят. На странице это сказано прямо, чтобы не создавать впечатления полного покрытия.
Managed-кластер сообщает v1.29.4-eks-abc1234. Так можно?
Да, вставляйте как есть. Суффикс дистрибутива отбрасывается, используется upstream-релиз, потому что именно против него заводят адвизори. Учтите: managed-провайдеры бэкпортят исправления в свои сборки, поэтому фикс может быть уже установлен, даже если номер upstream-патча выше.
У части адвизори нет уровня серьёзности. Почему?
Они приходят из базы уязвимостей Go, где оценка CVSS есть не всегда. Они показываются как «без оценки» и всё равно учитываются: версия с такими адвизори никогда не получает A, потому что «без оценки» не значит «безопасно».
Что будет, если источник адвизори недоступен?
Вы получите ошибку, а не пустой список. Ответ «уязвимостей не найдено» из-за неудавшегося запроса был бы самым опасным возможным выводом такого инструмента.
Почему статус поддержки влияет на оценку?
Потому что линия релизов после окончания поддержки больше не получает патчей безопасности. Любое адвизори, опубликованное после этой даты, останется в вашем кластере неисправленным, что бы вы ни делали, кроме обновления.