Гайд для разработчиков, инженеров DevSecOps и руководителей по тому, как превратить разрозненные сканирования в единый измеримый процесс при работе с Yandex Cloud.
В современной инфраструктуре с множеством команд, реестров контейнеров и кластеров Kubernetes® отслеживание уязвимостей превращается в сложную задачу: частые обновления образов создают риск пропустить критическую уязвимость.
Yandex Security Deck помогает решить эту проблему за счёт выстраивания целостного процесса: от автоматического обнаружения уязвимостей в контейнерных образах до приоритизации и контроля их устранения.
В этой статье пошагово разберём, как внедрить такой процесс с помощью модуля управления уязвимостями (Vulnerability Management, VM) в Yandex Security Deck.
Модуль «Управление уязвимостями» поддерживает работу с двумя типами реестров и одним источником образов рантайма. Это даёт широкие возможности для контроля безопасности контейнерной инфраструктуры:
Как подключиться
Доступ к реестрам и кластерам настраивается на уровне окружений Yandex Security Deck. Окружение — это контейнер настроек: оно определяет, какие именно ресурсы будут находиться под контролем системы. Чтобы подключить нужные ресурсы, достаточно назначить сервисному аккаунту роль security-deck.worker на выбранный каталог или облако. Вам не придётся выполнять сложные манипуляции с IAM — процесс подключения остаётся максимально простым и прозрачным.
Сканирование может запускаться автоматически — предусмотрено три сценария, при которых это происходит. При необходимости их можно комбинировать между собой, чтобы обеспечить максимальное покрытие и не упустить потенциально опасные ситуации.
Экран донастройки модуля «Управление уязвимостями»
Подход в разработке и обеспечении безопасности, при котором проверки и контроль качества переносят на максимально ранние этапы жизненного цикла продукта.
Триггер срабатывает сразу после выполнения команды docker push в любой из подключённых реестров. При этом фильтрация по тегам не предусмотрена: сканируется каждый новый загружаемый образ.
Такой подход соответствует режиму Shift Left: уязвимости выявляются ещё до того, как образ попадёт в продакшен. Это позволяет устранить проблемы на ранних этапах разработки и снизить риски для рабочей среды.
Этот сценарий предполагает периодический запуск сканирования для всех образов в выбранных реестрах. В пользовательском интерфейсе можно задать интервал проверки в днях — доступны предустановленные значения (7, 14, 30 дней) и возможность указать произвольный период.
Дополнительно есть опция «Сканировать только последний добавленный образ или образ с тегом latest». Она помогает сократить затраты: система не использует ресурсы на проверку устаревших активов, фокусируясь на актуальных версиях.
Совет
Воспользуйтесь этой опцией, если храните в реестре много старых образов, которые больше не используете. Для комплаенс‑аудита мы рекомендуем отключать эту настройку и сканировать все образы — так вы получите полную картину состояния инфраструктуры. Учтите, что каждый сканируемый образ — это тарифицируемый актив, поэтому объём проверок нужно заранее закладывать в бюджет.
Триггер активируется в момент, когда образ деплоится в кластер Kubernetes, который находится под управлением модуля контроля Kubernetes. Как только это происходит, образ автоматически попадает под контроль модуля «Управление уязвимостями». Если в нём обнаружатся уязвимости, они сразу отобразятся на дашборде.
Этот сценарий реализует режим рантайм‑безопасности: вы получаете актуальную информацию о том, какие образы реально работают в кластерах и какие угрозы они могут нести.
После завершения сканирования модуль формирует несколько ключевых сущностей, которые помогают эффективно анализировать и устранять угрозы.
Для каждого проверенного образа в таблице отображаются:
Результаты можно фильтровать по реестру, тегу и уровню риска. Это позволяет быстро сфокусироваться на наиболее важных или проблемных образах.
Главный экран модуля показывает наглядную сводку о состоянии безопасности инфраструктуры. На дашборде отображаются:
Дашборд поддерживает два способа группировки данных:
Главный дашборд модуля «Управление уязвимостями»
Контекст по уязвимостям в области сканирования: показывает не только, где и какая уязвимость найдена, но и подсвечивает риски и критичность
Все обнаруженные уязвимости автоматически попадают в модуль «Алерты» — единый интерфейс для просмотра уведомлений о проблемах безопасности. Для каждого алерта доступна дополнительная информация об уязвимости, список затронутых ресурсов, и рекомендации по устранению проблемы.
Сейчас платформа не поддерживает вебхуки для интеграции с Jira или Slack «из коробки»: алерты остаются внутри Yandex Security Deck. Но вы можете экспортировать данные, интегрировать их с вашей внутренней системой через API и гибко настраивать процессы мониторинга и реагирования.
В «Алертах» можно централизованно смотреть информацию по всем модулям Yandex Security Deck, в том числе по модулю «Управление уязвимостями»
О каждом алерте модуль даёт дополнительную информацию, перечень затронутых ресурсов, источник и рекомендации по устранению проблемы
Важно
Yandex Security Deck использует в том числе локальную базу данных уязвимостей, актуальную для российского рынка. Благодаря этому вы получаете не только информацию о международных CVE, но и данные об уязвимостях, актуальных с точки зрения российского законодательства и требований регуляторов.
Вы загружаете образ в реестр, а спустя неделю выясняется, что в нём содержится библиотека с известной уязвимостью. В результате приходится заново пересобирать образ, повторно тестировать и перекатывать его в продакшен — всё это отнимает время и ресурсы.
Активируйте триггер «При загрузке образа». После каждой операции docker push модуль «Управление уязвимостями» будет автоматически запускать сканирование загруженного образа. Результаты проверки сразу отобразятся в системе: либо подтвердится отсутствие уязвимостей, либо покажется список найденных CVE и уровень их критичности.
Активация модуля «Управление уязвимостями» в шаге «Модули контроля» при создании или редактировании окружения. Этот модуль не привязан к стандартам безопасности и включается вручную
Уязвимости выявляются на этапе сборки. Время между появлением уязвимости и её обнаружением (MTTD) сводится практически к нулю. В результате образы с критическими CVE не попадают в продакшен, а риски для безопасности инфраструктуры снижаются.
В реестре могут находиться сотни образов. Одни обновляются ежедневно, другие не меняются годами. При этом критически важно гарантировать, что ни один из них не содержит критических уязвимостей, особенно при подготовке к аудитам и проверкам.
Настройте триггер «По расписанию» с интервалом в семь дней. Включите опцию сканирования всех образов без фильтрации по тегу latest и дате последнего сканирования. Система соберёт полный список образов, проведёт проверку и покажет результаты на дашборде.
Включение проверки всех образов по расписанию. Система соберёт полный список образов и отобразит результаты на дашборде
Вы получаете документальное подтверждение постоянного контроля безопасности, готовый отчёт для аудита. Кроме того, вы можете отслеживать динамику: видеть, растёт или снижается общее количество уязвимостей. Это позволяет объективно оценить эффективность процессов патч‑менеджмента и своевременно вносить коррективы.
Даже если вы уверены, что образы в реестре безопасны, есть риск, что кто‑то запустит старую версию или использует образ из непроверенного источника. В результате в рабочей среде может оказаться компонент с известными уязвимостями.
Подключите кластеры к модулю контроля Kubernetes, а затем, при настройке модуля «Управление уязвимостями» в том же окружении, активируйте триггер «При использовании образа». Теперь каждый раз, когда в кластере создаётся под с новым образом, он автоматически проверяется на наличие уязвимостей. Если система находит критическую уязвимость, информация о ней сразу отображается на дашборде VM‑модуля.
Настройка автоматического сканирования: связка модуля контроля Kubernetes с триггером «Только образы, запущенные в кластерах» для дальнейшего сканирования в модуле управления уязвимостями
Реализуется принцип нулевого доверия для кластера — вы видите, что хранится в реестре и что реально запущено в рабочей среде. Это исключает ситуацию, когда формально всё чисто, но в продакшене по‑прежнему работает старый образ.
Приходит внешний аудитор и запрашивает отчёт о том, как вы контролируете уязвимости в контейнерных образах. Нужно продемонстрировать налаженный процесс контроля.
Откройте дашборд модуля «Управление уязвимостями», выберите нужный период (например, последние 30 дней) и экспортируйте историю сканирований. В сформированном отчёте будет отражена полная картина:
Аудитор получает полную прозрачность процесса. Вы можете показать итоговые результаты и динамику изменений — например, продемонстрировать, что количество уязвимостей последовательно снижается.
Начните с создания окружения в Yandex Security Deck. На этом этапе укажите, какие каталоги и облака будут находиться под контролем системы. Затем назначьте сервисному аккаунту роль security-deck.worker для доступа к выбранным ресурсам.
После этого донастройте модуль — уточните, какое количество реестров будет участвовать в контроле. Для этого перейдите в блок «Область действия контроля» и выберите нужные ресурсы в пределах созданного окружения. Доступные варианты:
Чтобы обеспечить максимальное покрытие, рекомендуем такую конфигурацию триггеров:
После того как вы сохраните настройки окружения и донастроите модуль «Управление уязвимостями», система начнёт работать. Через некоторое время вы увидите результаты первого сканирования — они отобразятся в интерфейсе модуля.
Разработайте и внедрите политику ремедиации внутри команды. Чёткие правила помогут оперативно устранять угрозы. Пример такой политики:
Все уязвимости с уровнями критичности Critical и High автоматически попадают в модуль «Алерты». Там их можно отслеживать в реальном времени, группировать по разным критериям и назначать ответственных за устранение.
Настройте дашборд под конкретные задачи вашей команды. В зависимости от способа группировки данных вы получите разную аналитику. Группировка по уязвимостям покажет, какие CVE наиболее распространены в вашей инфраструктуре, поможет выявить системные проблемы и сосредоточить усилия на их решении. Группировка по образам подсветит команды или сервисы, которые требуют повышенного внимания из‑за большого числа уязвимостей.
Регулярно отслеживайте динамику показателей. Если количество уязвимостей растёт, это сигнал, что ремедиация работает неэффективно и требует корректировки. Если число уязвимостей снижается, значит, принятые меры дают результат и вы движетесь в правильном направлении.
На дашборде отображаются три последних результата сканирования — это позволяет быстро оценить текущую ситуацию и изменения за последнее время.
Периодически выгружайте полную историю сканирований. Эти данные могут пригодиться для предоставления внешним аудиторам, чтобы подтвердить соблюдение требований безопасности, или для интеграции с BI‑системами, чтобы строить метрики, отчёты и визуализировать динамику безопасности инфраструктуры.
Чтобы показать ценность модуля «Управление уязвимостями» руководству, можно использовать такие метрики:
В ближайшее время модуль получит функциональность для анализа безопасности веб‑приложений и API, запущенных на виртуальных машинах, — с поддержкой DAST‑сканирования.
Сканирование позволит выявлять уязвимости из списка OWASP® Top 10, включая SQL‑инъекции, XSS, SSRF, XXE и другие.
Будут доступны три режима:
Управление уязвимостями — это непрерывный процесс: автоматическое обнаружение, приоритизация, ремедиация и контроль.
Модуль в Yandex Security Deck покрывает ключевые сценарии для контейнерных образов: проверку при загрузке, сканирование по расписанию и контроль при использовании в Kubernetes. Вы получаете единый дашборд, алерты, экспорт данных для аудита и соответствие российским регуляторам.
Воспользуйтесь Yandex Security Deck
Создайте окружение, подключите реестры, настройте триггеры и запустите первое полное сканирование. Выстройте политику ремедиации и используйте дашборд для регулярного мониторинга.
