Контейнерный образ приносит в кластер не только ваш код, но и всё, что лежит под ним: базовый слой, системные пакеты, зависимости языка и артефакты сборки. Именно поэтому сканирование образов перестало быть “хорошей практикой на потом” и стало обычной частью цепочки поставки - от сборки до реестра и дальше до кластера. Этот подход давно закреплён и в рекомендациях по контейнерной безопасности, включая NIST SP 800-190.
Проблема в том, что сам выбор сканера давно уже не сводится к вопросу “кто находит больше CVE”. Trivy сегодня выглядит как быстрый универсальный инструмент с упором на простую установку и широкий охват, Clair остаётся отдельным сервисом с архитектурой индексирования и сопоставления и хорошо ложится в сценарии вокруг реестров, а у Anchore актуальный открытый стек сейчас строится вокруг Syft и Grype, а не вокруг старого восприятия Anchore только как “ещё одного движка сканирования”. Даже в Harbor это хорошо видно: встроенный путь сейчас завязан на Trivy, а остальные сканеры подключаются уже как внешние.
Именно поэтому сравнивать такие инструменты мы будем не по рекламным обещаниям, а по рабочим вопросам. Насколько быстро они сканируют холодный и повторный образ. Как ведут себя на разных базовых слоях и зависимостях. Где шумят, где недосчитывают, как работают со SBOM и насколько удобно встраиваются в реестр, CI/CD и сам Kubernetes-поток. В этой статье мы как раз и разберём Trivy, Clair и Anchore в такой практической рамке - не как абстрактные “лидеры рынка”, а как три разных способа встроить управление уязвимостями в контейнерную платформу. Harbor уже умеет автоматическую генерацию SBOM с Trivy, а в экосистеме Anchore SBOM и сканирование уязвимостей тесно связаны через Syft и Grype.
Зачем вообще сканировать контейнерные образы
На практике контейнерный образ - это переносимый слепок всей среды, с которой приложение приезжает в кластер. Вместе с кодом туда попадают базовый слой, системные пакеты, библиотеки, зависимости языка, артефакты сборки и иногда то, чего в рабочем образе вообще не должно быть. Именно поэтому разговор о безопасности Kubernetes почти всегда быстро упирается не только в манифесты и политики кластера, но и в то, что именно команда кладёт в образ.Сканирование образов давно перестало быть формальной галочкой перед релизом. Оно нужно не для красивого отчёта по CVE, а чтобы у команды появился управляемый способ увидеть, какой риск она вообще несёт в кластер. Если этого нет, Kubernetes получает уже собранный и уже размноженный артефакт, внутри которого могут жить устаревшие пакеты, уязвимые зависимости, лишние инструменты, секреты в слоях и просто неаккуратная логика сборки. После публикации в реестр такой образ быстро начинает расходиться по средам, и исправление одной проблемы превращается уже не в задачу сборки, а в задачу догоняющего контроля.
Поверхность атаки образа: базовый слой, пакеты, зависимости, секреты, ошибки сборки
Первая ошибка в этой теме - думать, что риск контейнерного образа начинается и заканчивается базовым слоем. Да,alpine, ubuntu, debian, distroless и другие основы действительно определяют большую часть системной поверхности атаки. Но реальный риск почти всегда шире. Образ набирает проблемы сразу из нескольких источников, и именно это делает его сложным объектом для проверки.Ниже лежит системный уровень: пакеты ОС, криптографические библиотеки, сетевые компоненты, стандартные утилиты и всё, что тянется из базового образа. Выше - прикладной уровень: зависимости языка, транзитивные библиотеки, lock-файлы, менеджеры пакетов и вспомогательные модули, о которых команда может даже не помнить после пары релизов. Ещё выше - сам процесс сборки: лишние слои, неочищенные временные файлы, секреты в истории образа, запуск от root, слишком тяжёлый runtime-слой, мусор из промежуточных этапов multi-stage. В результате образ опасен не только тем, что в нём есть известная уязвимость, но и тем, что он часто содержит больше, чем нужно для работы приложения.
Именно поэтому команде нужен не просто сканер “с побольше CVE”, а инструмент, который соответствует реальной структуре её образов и её процессу сборки.
Где и когда сканировать: сборка, реестр, развёртывание
Сканирование образов перестаёт быть полезным, если делается только в одной точке. Если команда проверяет образ только перед релизом, она слишком поздно узнаёт о проблемах. Если сканирует только в CI, но не контролирует, что в итоге лежит в реестре и что реально уходит в кластер, она теряет связь между результатом проверки и фактическим развёртыванием. В Kubernetes это особенно неприятно, потому что артефакт проходит через несколько этапов, и на каждом из них уже можно потерять управляемость.На этапе сборки сканирование помогает отсечь явные проблемы до публикации. Здесь удобно ловить уязвимые зависимости, опасные базовые слои, ошибки в сборке и грубые конфигурационные просчёты. На этапе хранения в реестре сканирование становится уже не столько фильтром, сколько точкой централизованной видимости: какие образы вообще лежат в организации, что из них активно используется, где копятся старые теги и где одна и та же проблема расходится по нескольким командам. Перед развёртыванием в кластер проверка начинает играть роль политики допуска: можно ли запускать этот образ вообще, соответствует ли он внутренним требованиям и совпадает ли он с тем артефактом, который команда когда-то проверяла.
Из-за этого сам жизненный цикл важнее отдельного инструмента. Один и тот же сканер может показывать хорошие результаты в CI, но быть неудобным как сервис для реестра. Другой лучше встраивается в сканирование на уровне реестра, но слабее подходит для быстрого локального контроля на этапе сборки. Третий хорош там, где важны политика, повторяемость и отчётность. Именно поэтому вопрос "что выбрать" почти всегда начинается не с названия продукта, а с ответа на более неприятный вопрос: где в процессе команда вообще хочет принимать решение об уязвимости - до публикации, в реестре, на допуске в кластер или на всех этапах сразу.
Почему один и тот же образ даёт разный результат в разных сканерах
Ожидание у большинства команд довольно прямое: если образ один и тот же, результат проверки тоже должен быть одинаковым. На практике это почти никогда не так. Разные сканеры по-разному собирают и обновляют свои базы, по-разному сопоставляют пакеты с уязвимостями, по-разному работают с дистрибутивами, языковыми зависимостями и версиями библиотек. Даже когда речь идёт об одном и том же CVE, логика интерпретации может расходиться.Именно поэтому сравнение сканеров нельзя сводить к принципу "кто нашёл больше". Большее число находок не всегда означает лучший результат. Иногда это более широкое покрытие. Иногда - шум, дубли и спорные совпадения. Иногда сканер показывает проблему по данным общего справочника, а другой аккуратнее учитывает состояние пакета у конкретного вендора. Иногда один инструмент лучше понимает системный слой, а другой - прикладные зависимости. Для команды важна не только цифра в отчёте, но и то, насколько этот отчёт пригоден для работы: можно ли по нему принимать решения, не утонет ли процесс в ложных тревогах и насколько стабильно один и тот же образ будет оцениваться в разных контурах.
Поэтому сравнивать такие инструменты нужно не только по числу CVE, но и по типу результата: скорости, полноте, шуму и пригодности отчёта для реальной работы.
| Где возникает риск | Что именно нужно видеть | Почему одной проверки недостаточно |
|---|---|---|
| Базовый слой | Пакеты ОС, системные библиотеки, устаревшие компоненты | Один и тот же base image разные сканеры читают по-разному |
| Зависимости приложения | Прямые и транзитивные зависимости языка | Не каждый инструмент одинаково хорошо понимает стек и lock-файлы |
| Сборка и конфигурация | Секреты, root, лишние слои, ошибки Dockerfile | Это уже не только CVE, а более широкий класс проблем |
| Жизненный цикл | Что проверили, что опубликовали, что реально ушло в кластер | Без связи между этапами результат быстро теряет смысл |
Сканирование образов нужно потому, что именно образ становится точкой, где технический риск начинает масштабироваться. Один неудачный слой, один устаревший базовый образ или одна плохо контролируемая зависимость легко превращаются в проблему не для одного сервиса, а для всей цепочки сборки и развёртывания.
Три подхода к сканированию: Trivy, Clair и Anchore
Вопрос “чем сканировать образы” на практике почти всегда означает выбор между тремя моделями: быстрый инструмент для CI и локальной проверки, отдельный сервис вокруг реестра или более управляемый процесс, где сканирование связано со SBOM и политикой проверки. Именно поэтому Trivy, Clair и Anchore не стоит сравнивать как три “примерно одинаковых сканера”. Они решают похожую задачу, но делают это в разной эксплуатационной логике.Ещё одна важная поправка касается самого Anchore. Если несколько лет назад его часто воспринимали через призму Anchore Engine, то в 2026 году открытый стек Anchore уже логичнее описывать через Syft + Grype, а не через старый Engine как главный путь внедрения. Docker Hub прямо помечает Anchore Engine как больше не поддерживаемый, а сама Anchore-экосистема в открытом виде делает ставку на генерацию SBOM и сканирование через Syft и Grype.
Trivy: быстрый all-in-one путь
Trivy сегодня удобнее всего воспринимать как сканер с очень низким порогом входа и очень широкой зоной покрытия. Он умеет работать не только с уязвимостями в контейнерных образах, но и с ошибками конфигурации, секретами, SBOM, файловыми системами, удалёнными репозиториями, Kubernetes и облачными объектами. Для команды это означает простую вещь: Trivy легко становится первым инструментом, который подключают в pipeline, в локальную проверку разработчика и в базовый контроль артефактов без отдельной тяжёлой инфраструктуры.Именно отсюда у Trivy его главное преимущество. Он хорошо ложится туда, где нужен быстрый ответ и понятный CLI-поток: собрали образ, просканировали, получили результат, при необходимости сгенерировали SBOM, отдали отчёт дальше в CI или в dashboard. В реестровых сценариях это тоже заметно: Harbor давно делает ставку именно на Trivy как на встроенный путь для статического анализа уязвимостей, а scanner adapter для Trivy остаётся стандартным вариантом интеграции.
Но эта же простота задаёт и предел. Trivy особенно хорош как универсальный инструмент для быстрого сканирования, однако в больших средах быстро появляются требования к централизованной политике, сервисному слою и более управляемой работе со SBOM и реестром. И вот в этот момент сравнение уже перестаёт быть разговором про скорость запуска и начинает переходить к архитектуре.
Clair: сервисное сканирование вокруг реестра
Clair исторически интересен не тем, что он “ещё один CLI”, а тем, что он устроен как отдельная scanning-служба. В его текущей модели индексирование содержимого образа и сопоставление уязвимостей разделены: indexer строит представление о содержимом манифеста и слоёв, matcher сопоставляет этот результат с базой известных уязвимостей, а обновление данных идёт через updater-механику. Для команды это важно не как красивая архитектурная деталь, а как эксплуатационная модель: Clair удобнее там, где сканирование воспринимают как сервис вокруг образов, а не только как шаг в CI.Это особенно заметно в сценариях вокруг реестра. Harbor, например, с версии 2.2 больше не использует Clair как встроенный путь по умолчанию, но по-прежнему позволяет подключать его как внешний scanner. Clair остаётся актуальным там, где сканирование уже отделено от локального CLI-потока и живёт как самостоятельная сервисная часть платформы.
У Clair сильная сторона именно в этой разделённой модели. Он лучше смотрится там, где команда хочет централизовать индексацию и сопоставление, работать с образами через отдельный API-слой и строить scanning around registry, а не scanner in pipeline. Но цена этого подхода понятна: порог внедрения и сопровождения выше, чем у Trivy. Clair редко выигрывает простотой. Он выигрывает тогда, когда архитектура важнее удобства быстрого локального старта.
Anchore: SBOM, scanning и политика как единый процесс
С Anchore в 2026 году лучше сразу говорить точно. Если оставить за скобками старый образ “Anchore Engine как основной open-source scanner”, то открытая Anchore-экосистема сегодня читается через Syft и Grype: Syft отвечает за генерацию SBOM, Grype - за сканирование уязвимостей по образам, файловым системам и самим SBOM. Anchore прямо позиционирует свой открытый стек как набор инструментов для SBOM, vulnerability scanning и лицензий, а не как один монолитный движок старого типа.Это сразу меняет и сам характер сравнения. Anchore-подход сильнее не там, где нужен самый быстрый старт, а там, где команда хочет строить более управляемый процесс вокруг артефактов: сначала получить качественный SBOM, потом использовать его в сканировании, потом связать результат с политикой и требованиями к релизу. В enterprise-линейке Anchore это ещё усиливается policy-моделью и интеграциями, но даже в открытом виде связка Syft + Grype уже хорошо показывает, в чём идея: не просто проверить образ “на сколько-то CVE”, а встроить его в более широкий supply chain и compliance-контур.
Из-за этого Anchore-экосистема особенно уместна там, где важен не только сам факт проверки образа, но и воспроизводимый процесс со SBOM, разделением инвентаризации компонентов и политикой принятия решений. Для небольшой команды это может оказаться тяжелее, чем нужно. Для платформы с требованиями к контролю и отчётности - наоборот, именно это и становится главным аргументом.
Сравнительный тест на типовых образах
Сравнение сканеров имеет смысл только тогда, когда тестовый набор не сводится к одному “удобному” образу. В Kubernetes рядом почти всегда оказываются минимальные системные образы, полноценные базовые дистрибутивы, языковые рантаймы и собственные multi-stage сборки, поэтому тест должен покрывать несколько разных типов риска.
Тестовые образы: Alpine, Ubuntu, Node.js, Python и custom multi-stage
Набор образов лучше собирать так, чтобы он покрывал не только разные базовые слои, но и разные эксплуатационные сценарии. Минимальный Alpine нужен не ради моды на “лёгкие” образы, а потому что он хорошо показывает, как сканеры ведут себя на компактном дистрибутиве с собственной экосистемой пакетов. Ubuntu, наоборот, полезен как полноразмерный системный слой, где объём пакетов и advisory заметно выше, а значит лучше видна разница в покрытии и интерпретации уязвимостей.Образы
node и python нужны уже по другой причине. Они показывают не только уязвимости базового дистрибутива, но и то, насколько уверенно инструмент работает с прикладным стеком. Это особенно важно, потому что в реальных командах вопрос часто упирается не в “видит ли сканер libc”, а в том, насколько хорошо он понимает языковые зависимости и что именно считает частью итогового риска. Собственный multi-stage образ завершает картину: именно на нём хорошо проявляется, как инструмент справляется с результатом неидеальной сборки, лишними слоями, артефактами промежуточных этапов и более приближённой к реальности структурой образа.| Образ | Зачем он нужен в тесте | Что на нём лучше всего видно |
|---|---|---|
alpine:3.19 | Минимальный системный слой | Поведение сканера на компактном дистрибутиве и musl-экосистеме |
ubuntu:24.04 | Полноценный базовый образ | Глубину анализа системных пакетов и различия по advisory |
node:20 | Языковой runtime с зависимостями | Насколько хорошо сканер видит сочетание ОС и прикладного стека |
python:3.12 | Ещё один массовый прикладной стек | Уверенность в работе с пакетами языка и базовым слоем |
custom multi-stage | Реалистичный образ команды | Итоговую чистоту runtime, лишние слои и эффект реальной сборки |
Что измеряем: время, CVE, severity, уникальные находки
Первая метрика, на которую команды обычно смотрят, - скорость. Но сама по себе она легко вводит в заблуждение. Холодное сканирование и повторная проверка с кэшем - это две разные истории. Инструмент может быть не самым быстрым при первом запуске, но вести себя вполне комфортно в ежедневном CI-потоке. Или наоборот: резко стартовать на простом образе, но хуже масштабироваться на более тяжёлых и насыщенных пакетами артефактах. Поэтому время имеет смысл смотреть как минимум в двух режимах: cold scan и cached scan.Вторая группа метрик - сами находки. Здесь важно не только общее число CVE, но и их распределение по критичности, а также расхождения между инструментами. Один сканер может найти больше критичных и высоких, другой - больше средних и низких, третий - показать более широкий список за счёт разных источников данных об уязвимостях. Если смотреть только на общий счётчик, такая разница быстро превращается в иллюзию простого сравнения. На практике же команде нужен не “самый громкий” результат, а такой, который даёт управляемую картину риска и не перегружает pipeline лишним шумом.
Отдельно стоит смотреть на уникальные находки. Не в смысле, что любая уникальная CVE автоматически делает сканер лучше, а в смысле, что она показывает различие в модели анализа. Иногда это реальное преимущество покрытия. Иногда - следствие того, как инструмент работает с advisory-базой конкретного дистрибутива или языка. Иногда - лишний шум, который при ручной проверке не подтверждается. Именно поэтому качественное сравнение сканеров почти всегда упирается не только в количество, но и в характер расхождений.
Где обычно расходятся результаты
Самые интересные различия между сканерами почти никогда не лежат на поверхности. На простом уровне все три инструмента обычно достаточно уверенно видят базовые проблемы в популярных слоях. Расхождения становятся заметнее там, где начинается интерпретация: вендорские исправления без смены исходной версии проекта, разные advisory-источники, языковые зависимости, устаревшие пакеты и логика сопоставления компонентов с уязвимостями.Именно здесь и видно, что один и тот же образ даёт не просто разное количество находок, а разный тип результата. Различие становится заметным только тогда, когда отчёт оценивают не по числу CVE, а по его пригодности для реальной работы команды.
Как правильно смотреть на false positive и “лишний шум”
В сканировании образов термин false positive почти всегда требует аккуратности. Очень часто команда называет ложным срабатыванием не ошибку как таковую, а неудобный или спорный результат. Например, сканер показывает CVE, которая есть в общем справочнике уязвимостей, но у дистрибутива уже закрыта через backport. Или уязвимость формально относится к компоненту, который есть в образе, но не используется в том виде, как предполагает advisory. Или одно и то же семейство проблем начинает дробиться на несколько находок, которые в отчёте выглядят тяжёлыми, но практически плохо различаются.Поэтому ручная верификация здесь нужна не для того, чтобы “поймать сканер на ошибке”, а чтобы понять характер его шума. Один инструмент может чаще завышать риск там, где advisory трактуется слишком широко. Другой - наоборот, быть более консервативным, но за счёт этого уступать в охвате. Для команды это критично, потому что шум быстро превращает сканирование из полезного фильтра в раздражающий формальный этап, который начинают обходить или принимать не всерьёз. Именно на этом месте и проявляется зрелость инструмента: не только сколько он нашёл, но и сколько из этого результата команда реально готова брать в работу.
Интеграция в CI/CD и Kubernetes
Ценность сканера начинается не в тот момент, когда он умеет показать список CVE, а в тот момент, когда результат можно встроить в реальный путь артефакта: сборка, публикация, реестр, допуск в кластер и повторная проверка уже используемых образов.В Kubernetes это особенно чувствительно. Проверка только в CI даёт ранний сигнал, но хуже связывается с тем, что реально осталось в реестре и ушло в кластер. Проверка только в реестре даёт централизованную видимость, но не всегда останавливает плохой образ достаточно рано. Проверка только на admission-уровне часто срабатывает уже в момент развёртывания. Поэтому интеграция здесь важна не как “ещё одна галочка DevSecOps”, а как выбор точки, в которой команда хочет принимать решение о риске.
GitLab CI и GitHub Actions
Для CI-сценариев Trivy сегодня остаётся самым прямым и практичным вариантом. GitLab в своём контейнерном сканировании делает ставку именно на Trivy, а результаты сканирования дальше попадают в security-функции платформы, включая dashboard и общий контекст по уязвимостям проекта. Это делает Trivy очень удобным там, где команда хочет получить быстрый и понятный путь “собрали образ -> просканировали -> увидели результат в интерфейсе GitLab”, без отдельной тяжёлой scanning-инфраструктуры.В GitHub Actions картина похожая, но модель более конструкторская. Для Trivy есть официальный action, а результаты можно отдавать в SARIF и загружать в GitHub Code Scanning. Это особенно удобно там, где команда уже живёт в процессе, который уже целиком построен вокруг GitHub и хочет встроить сканирование образов в тот же поток, где идут тесты, сборка и публикация артефактов. Это снова делает Trivy сильным именно в CI-контуре: быстрый запуск, понятный CLI и стандартный путь вывода результатов.
Anchore в этом же контуре выглядит немного иначе. Если смотреть на открытую экосистему Anchore через Syft и Grype, то она хорошо подходит там, где вместе со сканированием команда хочет сразу получать SBOM и выстраивать более управляемый процесс вокруг артефакта. Это уже не настолько “zero-config” история, как у Trivy, но зато лучше ложится в сценарии, где важен не только быстрый fail на критичных CVE, но и сам артефактный контекст. В CI это чаще всего означает более зрелый и чуть более тяжёлый процесс, а не просто мгновенный фильтр.
Реестр образов: Harbor, встроенный Trivy и внешний Clair
Когда центр тяжести смещается в сторону реестра, логика выбора меняется. Harbor в актуальной документации делает встроенную ставку на Trivy, а Clair остаётся доступным как внешний scanner. Если команде нужен самый прямой и поддерживаемый встроенный путь в современном Harbor, Trivy выглядит естественным выбором. Он даёт статический анализ уязвимостей по образам, умеет работать по расписанию и ложится в ту модель, где реестр становится централизованной точкой контроля.Clair сохраняет смысл в другом сценарии. Его сила не в том, что он “лучше встроен в Harbor по умолчанию”, а в том, что он остаётся отдельным scanning-сервисом с собственной архитектурой. Для команды это полезно там, где реестр — не просто место хранения артефактов, а часть отдельной scanning-службы. Clair оправдан там, где команда сознательно хочет сервисную модель indexer/matcher вокруг образов.
Anchore в реестровом контуре обычно интересен уже не как просто сканер CVE, а как часть более широкого policy и compliance-потока. В актуальной Anchore-документации и релизах видно, что экосистема в 2026 году продолжает жить вокруг Syft, Grype, enterprise-компонентов и отдельных интеграций, включая Harbor scanner adapter и admission-контур. Это делает Anchore особенно уместным там, где реестр включён в более жёсткий управляемый процесс, а не только в публикацию образа и разовый security check.
Kubernetes: оператор, контроль допуска и реальная видимость
В самом Kubernetes различие между инструментами становится ещё интереснее, потому что здесь команда работает уже не только с “образом как файлом”, а с образом как реально используемым артефактом внутри кластера. Trivy Operator здесь особенно силён. Он наблюдает за изменениями в кластере и автоматически создаёт отчёты безопасности в виде Kubernetes CRD, включая vulnerability reports по образам, которые реально используются подами. Это очень важный сдвиг: вместо абстрактного знания “когда-то этот образ был просканирован” команда получает непрерывную видимость того, что фактически живёт в кластере.Здесь же возникает admission-сценарий. С точки зрения Kubernetes admission controller — это код, который перехватывает запросы к API server до сохранения объекта. Именно в этой точке команда может пытаться не только видеть риск, но и влиять на допуск образа в кластер. Для policy-ориентированных сценариев это особенно ценно: проблема выявляется не после запуска, а в момент, когда образ ещё только пытается пройти в целевую среду.
Для Anchore это место тоже остаётся актуальным. В текущей документации Anchore Kubernetes Admission Controller продолжает существовать как поддерживаемый компонент с несколькими режимами работы, а в релизах Anchore Enterprise он по-прежнему фигурирует как поддерживаемая часть интеграционного контура. Это делает Anchore особенно интересным там, где команда хочет не просто отчёт о CVE, а решение на основе политики о том, можно ли вообще запускать образ в Kubernetes.
| Сценарий | Самый естественный выбор | Почему |
|---|---|---|
| Быстрый шаг в CI | Trivy | Минимальная настройка, понятный CLI, удобный путь в GitLab и GitHub Actions |
| Централизованное сканирование в реестре | Harbor + Trivy или Clair | Первый удобнее как встроенный путь, второй — как отдельный scanning-сервис |
| SBOM-first процесс в CI | Anchore / Syft + Grype | Удобнее там, где важен не только CVE-отчёт, но и управляемый артефактный контекст |
| Непрерывная видимость в Kubernetes | Trivy Operator | Даёт CRD-отчёты по реально используемым образам |
| Контроль допуска по политике | Anchore admission или аналогичный admission-подход | Нужен там, где команда принимает решение до запуска образа |
Именно поэтому инструменты удобнее оценивать не в вакууме, а по той роли, которую они будут играть в реальном процессе команды.
Где управление уязвимостями становится процессом
Сканирование образов в Kubernetes давно перестало быть задачей “проверить перед релизом и забыть”. На практике это не отдельный security-шаг, а способ вернуть команде управляемость над тем, что именно она приносит в кластер. И именно здесь сравнение Trivy, Clair и Anchore оказывается полезным не как спор о лучшем сканере вообще, а как разговор о том, где в процессе команда хочет видеть риск, насколько рано хочет на него реагировать и что для неё важнее - быстрый результат, сервисная модель вокруг реестра или более жёсткий процесс со SBOM и политикой.У всех трёх подходов есть своя сильная сторона. Trivy выигрывает там, где нужен быстрый и понятный путь в CI и повседневную работу платформенной команды. Clair выглядит убедительнее в сервисной модели вокруг реестра. Anchore сегодня интереснее всего там, где разговор идёт уже не только о CVE, а о связке сканирования, SBOM и управляемой политики. Поэтому зрелый выбор здесь редко сводится к одному универсальному ответу.
Остаётся самый интересный вопрос для любой Kubernetes-команды: нужен ли вам просто сканер, который находит уязвимости, или процесс, в котором образ действительно остаётся под контролем от сборки до запуска?
Последнее редактирование:
