Сообщить об ошибкеКороткий ответ
Сканеры образов (Trivy, Grype, Docker Scout и аналоги) анализируют установленные пакеты во всех слоях образа и сверяют их версии с базами известных уязвимостей (CVE), позволяя обнаружить и заблокировать публикацию образов с критическими проблемами ещё в CI, до попадания в production.
Как это работает подробнее
сканер разбирает слои образа, строит список установленных пакетов ОС и, часто, зависимостей уровня языка (npm, pip, go modules), затем сопоставляет версии с публичными базами данных уязвимостей (NVD и производные источники) и выдаёт отчёт с уровнями критичности (CRITICAL, HIGH, MEDIUM, LOW).
Пример кода
Пример конфигурации
$ trivy image --severity CRITICAL,HIGH myapp:1.0
myapp:1.0 (debian 12.4)
=======================
Total: 3 (CRITICAL: 1, HIGH: 2)
┌──────────┬────────────────┬──────────┬───────────────┐
│ Library │ Vulnerability │ Severity │ Fixed Version │
├──────────┼────────────────┼──────────┼───────────────┤
│ openssl │ CVE-2024-XXXXX │ CRITICAL │ 3.0.13-1 │
└──────────┴────────────────┴──────────┴───────────────┘Что использовать на практике
- Практика. сканирование включают прямо в CI-пайплайн сборки образа, с правилом "сборка не проходит" (
exit code != 0), если найдены уязвимости выше заданного уровня критичности; важно также периодически пересканировать уже опубликованные образы, так как новые CVE для тех же версий пакетов обнаруживаются постоянно, даже без изменения самого образа.
Подводные камни
- Риск. сканируют образ лишь однократно при публикации и больше не возвращаются к нему, хотя новые уязвимости для тех же версий пакетов появляются со временем; блокируют весь пайплайн при любой найденной уязвимости без разделения по критичности, что на практике приводит либо к постоянным "красным" сборкам, либо к массовому игнорированию отчётов командой.