Журнал "Information Security/ Информационная безопасность" #3, 2025

База: Образы контейнеров Чтобы не быть голословными, давайте сначала разберемся, что такое образы контейнеров, из чего они состоят и как мы получаем ситуацию, описанную выше. По сути, образ контейнера – это архив в котором содержится приложение и все необходимые для его работы объекты: сторонние библиотеки, библиотеки для библиотек (и далее вглубь), файлы, директории, сторонние программы. С учетом того, что современные мик- росервисы на 60%–90% состоят из сто- роннего кода – в образах содержится очень много того, что писали и создавали не вы, а кто-то другой. Но! Все это теперь находится внутри вашего образа и влияет на общую безопасность микросервиса, то есть входит в вашу зону ответственно- сти. Стоит добавить, что содержимое добавляется в образ не одним скопом, а по слоям. Из этих слоев обычно строится несложная иерархия. Сначала идет базо- вый слой – обычно это слой ОС (напри- мер, Ubuntu, Debian, Astra Linux, ОС "Альт") со всеми ее компонентами. Даль- ше идет слой с рантаймом языка про- граммирования и его зависимостями (например, Java, Python, Ruby). Далее идет слой (или слои) со сторонними биб- лиотеками, которые являются зависимо- стями для вашего приложения (например, React, Spring, OpenSSL). И в заключении – ваше приложение, которое функциони- рует на базе всего, что находится в ниже- лежащих слоях. Поскольку идеальных приложений не существует, каждое из них содержит уязвимости, которые регулярно выявляются. Среди них встречаются как критически важные и действительно опасные, так и те, что никак не приме- нимы к вашему конкретному случаю. Кроме того, на управление уязвимостями влияет множество дополнительных фак- торов, усложняющих этот процесс. О них мы тоже поговорим. База: Жизненный цикл уязвимости Теперь давайте разберемся с класси- ческим жизненным циклом любой уязви- мости с того момента, когда она выявляет- ся, до того момента, как с помощью ска- нера мы находим ее в своей кодовой базе и выпускаем исправление. Фаза 1: Обнаружение уязвимо- сти разработчиком. Это может слу- читься при внутреннем или при внешнем тестировании, из программы баг-баунти, из инцидента безопасности у кого-то из ваших заказчиков. Важно понимать, что на текущий момент: 1) это уязвимость 0-day и для нее еще нет исправления, и 2) эта уязвимость есть у всех пользо- вателей данного компонента. Фаза 2: Выпуск патча и иден- тификатора CVE. Разработчик начи- нает работу над проблемой: анализирует уязвимость, готовит исправление, про- водит тестирование, выпускает патч. Параллельно может происходить регист- рация CVE – хотя это не гарантировано. Многое зависит от качества описания и желания разработчика признавать критичность: по понятным причинам ее нередко стремятся занизить. На этом этапе уязвимость переходит из статуса 0-day в статус 1-day. Фаза 3: Обновление feed-уязви- мостей. Разработчики Security-реше- ний обновляют свои базы знаний (feed) с актуальной информацией об уязвимо- стях. Например, в Luntry 1 это происходит ежедневно. На стороне заказчика такие обновления тоже должны применяться: где-то это происходит автоматически, где-то – требует дополнительной авто- матизации, особенно в закрытых конту- рах. Чем чаще происходит обновление, тем более свежими и релевантными данными вы располагаете. Фаза 4: Сканирование образов. Лишь теперь можно приступать к скани- рованию образов, чтобы выявить уже известную уязвимость. Здесь важно, насколько полно ваше окружение охваче- но сканерами, с какой периодичностью запускается сканирование, сколько у вас образов и каковы их размеры – все это влияет на длительность анализа. Добавим к этому и привычные уловки разработчи- ков, стремящихся пройти Quality Gate с первого раза, в том числе за счет обхода сканеров. Всё перечисленное напрямую влияет на скорость и точность выявления уязвимостей. А при этом в про- дакшене всё еще остается микросервис с уязвимостью, и атакующий уже в состоя- нии ее эксплуатировать! Фаза 5: Постановка задачи раз- работчикам. Обнаружение уязвимости – это лишь 10%–15% всей работы. Основ- ная сложность начинается позже: с поста- новки задачи на исправление. Этот про- цесс может быть как ручным, так и авто- матизированным, однако в некоторых окружениях мы наблюдаем сотни тысяч уязвимостей. Возникает необходимость приоритизировать: какие проблемы кри- тичны и требуют немедленного реагиро- вания, а какие могут подождать. Без этого хаос быстро парализует весь процесс. Фаза 6: Обновление компонен- та. Спустя какое-то время разработчик добирается до задачи, связанной с 64 • ТЕХНОЛОГИИ Контейнеры уязвимы. И что теперь? авайте без иллюзий: образы контейнеров без проблем и уязвимо- стей – миф. Даже если такой момент и наступает, это либо исключение, либо временное затишье. Но это точно не повод игнорировать безопасность. Напротив, к ней нужно подходить с умом, иначе ресурсов на реальное улучшение просто не хватит. Д Дмитрий Евдокимов, основатель и технический директор Luntry Рис. 1. Жизненный цикл уязвимости Фото: Luntry 1 https://luntry.ru/