Сканирование образов: почему жирная база везёт бэклог CVE и что Trivy и Grype реально измеряют

Что сканер реально делает — и чего нет

Прежде чем действовать по результатам скана, нужно понять, что инструмент вообще измеряет — потому что путаница между «числом найденных CVE» и «реальным риском для сервиса» ведёт либо к панике, либо к ложной уверенности.

Сканер уязвимостей контейнеров вроде Trivy или Grype в своей сути — это join. Сначала он строит Software Bill of Materials (SBOM): обходит слои образа и перечисляет каждый установленный артефакт, что может опознать — OS-пакеты из базы dpkg/rpm/apk плюс языковые зависимости из lock-файлов вроде package-lock.json, go.sum или Gemfile.lock — каждый с именем и точной версией. Затем он сопоставляет эти пары имя+версия с базой уязвимостей (NVD плюс distro-специфичные фиды вроде security-трекеров Debian и Alpine, GitHub-advisories и так далее) и выдаёт каждую CVE, чей диапазон затронутых версий включает то, что ты поставил. Это весь механизм, и его пределы вытекают прямо из него: сканер находит известные уязвимости в объявленных версиях. Он не знает, достигается ли уязвимый путь кода в рантайме, бэкпортнул ли фикс твой distro (частый источник ложных срабатываний, когда upstream-строка версии выглядит уязвимой, но distro пропатчил), и уязвимо ли вообще что-либо не из распознанного манифеста пакетов — руками curl-нутый бинарь, вендоренный .so. Сканирование измеряет твою поверхность экспозиции как объявлено, не твою эксплуатируемость.

Вот почему результат доминирует твоей базой, а не твоим кодом. Поставь на ubuntu или node — и сканер перечислит весь base-userland: типичная жирная база несёт 300-с-лишним OS-пакетов, и в любой момент срез из них имеет нерешённые high- или critical-CVE — не потому, что твой сервис небезопасен, а потому, что ты таскаешь почти полный Linux-дистрибутив, чтобы гонять один бинарь. Большинство этих пакетов — шеллы, пакетные менеджеры, библиотеки сжатия, интерпретатор-другой — никогда не вызываются твоим приложением. Это чистая поверхность атаки и чистый бэклог CVE. Самый эффективный сократитель результатов сканирования, стало быть, не патчинг, а удаление: distroless-база (лишь glibc, CA-сертификаты и твой рантайм, без шелла и пакетного менеджера) режет число пакетов до единиц, и число CVE схлопывается с ним, потому что попросту почти нечего сопоставлять с базой.

Чтение severity, исправимости и SBOM, что ты хранишь

Сканеры раскладывают находки по severity (CRITICAL/HIGH/MEDIUM/LOW, из CVSS) и, критично, по исправимости — есть ли фикс-версия. Число, что должно двигать действие, — это «critical и high с доступным фиксом», ведь это те, что бамп базы или обновление зависимости реально решает; остальные трекаются, не гонятся. Не менее важен артефакт, что скан попутно производит: SBOM ценен сам по себе. Сохранённый рядом с образом (в форматах вроде CycloneDX или SPDX, часто лишь десятки-сотни килобайт JSON), он позволяет ответить «затронуты ли мы завтрашней CVE?», запросив инвентарь, что ты уже записал, вместо пересканирования с нуля под давлением инцидента — а это ровно вопрос, что Log4Shell заставил каждую команду решить за ночь. Сканирование, стало быть, — два вывода: приоритизированный, осведомлённый об исправимости список находок, что двигает петлю ужми-базу-затем-патч, и долговечный SBOM, что превращает следующий zero-day из лихорадочных раскопок образа в запрос к базе.