Привет Хабр! Меня зовут Татьяна Хуртина, и я программист в группе внутренней автоматизации ИБ VK. Недавно я выступала на киберфестивале PHDays c докладом про наш подход для мониторинга безопасности контейнеров. На примере опыта в inhouse-облаке Дзена я рассказала, как можно использовать Open Source решения, чтобы искать уязвимости в Runtime. 

И сразу оговорюсь, что тут в понятие Runtime мы вкладываем мониторинг уязвимостей в запущенных в оркестраторе контейнерах в (почти что) реальном времени. 

Если перед вами стоит похожая задача, возможно, вам пригодится наш практический опыт. Публикую здесь ключевые мысли и схемы. 

Предпосылки 

Большинство IT-компаний сейчас используют контейнеры для развертывания инфраструктуры своих продуктов, при этом образы контейнеров могут содержать ошибки и уязвимости, которые могут нанести ущерб работе всего сервиса.Что касается ситуации в мире? По статистике Sysdig:  87% контейнеров в prod имеют высокие и критические уязвимости. Только 15% из них используются в runtime, да и не все уязвимости можно проэксплуатировать в принципе. Поэтому если объединить несколько критериев уязвимости (наличие исправления, использование в Runtime и возможность эксплуатации), то для исправления остается всего 2% уязвимостей. 

В разработке часто используются сторонние библиотеки, но ключевой вопрос безопасности – насколько им можно доверять? 

К примеру, когда разработчик делает pip install, то не очевидно, какие зависимости будут установлены. К тому же, существует множество методов подмены пакетов – к примеру, создание поддельных с похожими названиями. 

Также известно, что вредоносные зависимости наследуются из разных источников, и если не знать, где и какие библиотеки задействованы, то неясно, куда обратиться для устранения уязвимости. Мы не встраиваем проверки в pipeline, чтобы:

• не замедлять разработку и доставку продукта;

• критичность уязвимости должна определяться аналитиком, а не сканером (возможны ложные срабатывания);

• база уязвимостей постоянно пополняется (сейчас уязвимости нет – завтра ее обнаружат).

Поэтому лучше регулярно сканировать уже запущенный сервис, чтобы иметь актуальную информацию об уязвимостях. И устранять критические. Все это подводит к логической необходимости сквозного мониторинга для поиска критически важных уязвимостей и обеспечение комплексной безопасности уже функционирующего приложения. 

С чем мы столкнулись в Дзен? 

В Дзен нестандартная инфраструктура, развернутая во внутреннем облаке с иерархической системой организации структур и сервисов. Дзен использует десятки тысяч контейнеров, из них тысячи уникальных образов с сотнями различных зависимостей, и регулярно появляются новые образы. Кроме того, существуют требования по соблюдению SLA по сканированию в больших объемах. 

Для решения вопросов безопасности в Дзене реализована функция архитекторов ИБ – они проводят анализ продукта и формируют задания по безопасности, а в случае публикации уязвимости помогают быстро обнаружить проблему и предложить решение по исправлению. Поэтому нам надо было обеспечить архитекторов ИБ удобными инструментами контроля, которые позволяли бы закрыть задачи по инвентаризации – сколько и каких сервисов запущено, какие они имеют компоненты, какие лицензии компонентов; и задачи и по работе с уязвимостями – быстрому поиску, приоритезации и устранению.

Решение

Система для мониторинга безопасности контейнеров встраивается в классическую модель DevSecOps. С ее помощью мы работаем сразу на четырех этапах процесса. 

На этапе Release происходит анализ контейнеров и пакетов, на этапе Deploy – отслеживание зависимостей, на этапе Operate – анализ уже запущенных контейнеров, что позволяет реализовать механизм оперативного обнаружения уязвимых зависимостей и контейнеров. И все это, по сути, добавляет возможность наблюдения на этапе Monitor.

Внедрение контролей информационной безопасности в pipeline может привести к замедлению процессов разработки и доставки продукта, что нежелательно для бизнеса. Поэтому мы избегали встраивания в сборки. И по возможности стараемся сделать так, чтобы контроли ИБ для пользователя оставались незаметными.  

Мы сразу решили, что будем создавать собственное решение на базе Open Source. Основная причина – отсутствие на рынке подходящего решения, потому что у Дзена высокие нагрузки и своя нестандартная инфраструктура облаков. Кроме того, Open Source решение дает технологическую независимость разработки – мы не привязаны к определенному стеку и можем использовать различные связки, гибкость в корректировке ошибок по DPO, то есть выявленные баги можно править самому, а не ждать очередной патч от вендора.  

Из чего собирали 

Сперва мы взяли один из самых известных сканеров безопасности для поиска уязвимостей и ошибок в конфигурациях – Trivy. У него довольно широкий спектр задач, но нам он был больше интересен выявлением программных зависимостей из Docker-образов и выявлением уязвимостей.

К анализатору добавили платформу для управления безопасностью Dependency-Track, потому что ее дашборд позволяет увидеть общий обзор безопасности проекта, информацию о уязвимостях и рекомендации по их исправлению, список проектов и их текущий статус безопасности.  Это удобный инструмент для аналитиков ИБ, который позволяет видеть актуальное состояние зависимостей и их уязвимости. Он помогает приоритизировать уязвимости и оперативно реагировать на критически важные.

Однако, по нашему опыту Trivy сканируют на уязвимости лучше, чем это делают другие сканеры, в том числе и встроенный в Dependency-Track. Поэтому мы решили доработать Dependency-Track, создав плагин Trivy-REST, чтобы он ходил для проверки на уязвимости не в свои встроенные сканеры, а в Trivy. Таким образом мы обеспечили возможность автоматизированного сканирования компонентов и получения результатов анализом.

К этому добавили собственный сканер, написанный на Go. Он содержит планировщик, который собирает информацию о запущенных Docker-образах в облаке. Этот сканер с помощью Trivy создает SBOM и сохраняет базу данных. Также сканер отправляет эти данные из SBOM в Dependency-Track для дальнейшего анализа на уязвимости.

SBOM является ключевым элементом процесса выявления уязвимости. Он представляет собой перечень зависимостей, файлов, библиотек и других элементов, имеющих отношение к конкретному сервису или инфраструктуре целиком. Его основная задача — это предоставить наиболее полную информацию о зависимости, типах лицензий. 

 Для хранения SBOM мы выбрали формат CycloneDX, потому что его поддерживает и Trivy и Dependency-Track. Он содержит в себе информацию о метаданных, компонентах, зависимостях и уязвимостях. 

 Механика процесса 

1.  Сканер периодически запрашивает список запущенных в облаке образов, обеспечивая актуальность данных мониторинга.

2.  Сканер получает информацию по каждому образу из Registry. В качестве уникального идентификатора образов служит хеш-сумма (Digest) 

3.   Сканер посредством Trivy создает SBOM в формате CycloneDX и сохраняет его в базу данных.

4. Также сканер посредством другого планировщика создает проект в Dependency-Track и отправляет SBOM. Отправляются как новые SBOM, так и уже существующие. Поскольку база уязвимостей периодически обновляется, следует пересканировать уже существующие образы.

5. Dependency-Track, используя Trivy-REST, анализирует компоненты на уязвимости.

 Почему мы выбрали анализаторы Trivy, а не Dependency-Track?

Dependency-Track имеет несколько сервисов для выявления уязвимости – Internal, OSS Index, VulnDBи Snyk. В качестве источников для анализа уязвимостей он использует: NVD, GitHub Advisories и OSV.

NVD матчится по CPE, и тут происходит много ложных срабатываний. Сопоставление происходит по вендору, продукту и версию, а вендор зачастую некорректно заполнялся. Поэтому остаются только поля product и version, то есть экосистема, в которой существовал пакет, полностью не учитывалась.

GitHub Advisories и OSV мэтчатся по PURL, но GitHub Advisories анализирует уязвимости только проектов на GitHub, и они совокупно поддерживают меньше экосистем, чем Trivy.

Поэтому анализатор Trivy с открытым репозиторием обладает большим набором преимуществ. Особенно, это поддержка большого количества дистрибутивов Linux. У дистрибутивов Linux существуют свои листы с уязвимостей, и все эти листы в виде больших XML Trivy скачивает и складывает в свою базу уязвимостей.

Вместо заключения

Конечно, внутри этого решения есть еще много шагов для улучшения. Нужно доработать отказоустойчивость, UX/UI и улучшить скорость работы. Но уже сейчас сканеры за 30 минут анализируют порядка 200 образов с минимальной нагрузкой на облако. Сканирование происходит на отдельных мощностях чтобы не аффектить на продуктовые сервисы. Пошли в оптимизацию и сканируем только запущенные образы. Также, с помощью этого решения мы полностью закрыли задачи по инвентаризации и работе с уязвимостями.

Данная система может легко и в любой момент быть интегрирована в процессы обеспечения безопасности на любой инфраструктуре – Docker, Compose, Nomad, Kubernetes, даже если это уже функционирующее приложение. Оно позволит повысить эффективность взаимодействия команды ИБ и разработки, особенно, в части приоритизации задач по устранению уязвимостей.

PS: полную версию моего доклада вы можете посмотреть здесь.