Comments 6
Разрешите побыть адвокатом дьявола :)
50-метровый образ в проде - круто. 0 уязвимостей на сканере - круто
Но
это 50 метров - это на hello world. В жизни размер приложения с либами несколько сотен метров. иногда до гигабайта (у нас в основном java+springboot). И размер образа не так важен, как размер последнего часто меняющегося слоя
мы оптимизируем количество срабатываний сканера. А платим за это тем, что тестируем не тот дистрибутив, который будет в проде.
Вы правы, дело не в сокращении размера образа на несколько десяток мегабайт. Надо уменьшать количество компонентов в образе, которые не использует приложение, но которыми могут воспользоваться злоумышленники.
Приведу пример: в одной из библиотек приложения есть уязвимость RCE (удаленное выполнение кода). С установленными в контейнере утилитами, менеджером пакетов не составит труда снять дамп памяти вашего процесса и отправить его на удаленный сервер для последующего анализа. С другой стороны если в контейнере есть только рантайм и ваше приложение вектор атаки сильно сокращается.
Какого рода эти уязвимости, реально ли вообще ими воспользоваться ?
Если мы говорим о образах с .NET, то MS оперативно выпускает новые версии базовых образов с исправлениями и интересного на данный момент нет.
Но я просканировал образ, которые собирал более года назад (на основе последней доступной версий mcr.microsoft.com/dotnet/aspnet ) и нашел несколько интересных уязвимостей, которые потенциально могут привести к DoS или влиять на безопасность:
CVE-2023-36799 - A vulnerability exists in .NET where reading a maliciously crafted X.509 certificate may result in Denial of Service. This issue only affects Linux systems.
CVE-2023-4911 - buffer overflow in ld.so leading to privilege escalation
CVE-2023-36054 - krb5: Denial of service through freeing uninitialized pointer
CVE-2018-8292 - .NET Core: information disclosure due to authentication information exposed in a redirect
CVE-2023-36558 - ASP.NET Security Feature Bypass Vulnerability in Blazor forms
Любая зависимость и любая уязвимость усложняют жизнь. Даже если ими не реально воспользоваться, надо тратить время на ручной или полуручной анализ и обоснование этого. В некоторых отраслях мы это делаем «для себя», а в некоторых это может быть основанием для написания формальных документов и отдельное согласование с ИБ.
Упрощает дело анализ по категориям — отметаем все узявимости, которые имеют вектор атаки в доступом к USB на основании того, что средство контейнеризации и контроль физического доступа исключают этот вектор атаки и т.д., но все равно это время и расходы.
Чем меньше уязвимостей показывает сканер, тем лучше с точки зрения и реальной безопасности, и работы со службами ИБ и их требованиями.
В свое время тоже интересовался этой темой. Для AOT hello-world получил такой результат (PublishAot, StaticallyLinked, scratch):
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/dotnet-web-slim latest 19c432d03ca3 2 minutes ago 11.3 MB
localhost/dotnet-web latest a089d676d3fb 7 minutes ago 18.1 MB
Для редхатовского ubi-micro такой (PublishSingleFile, PublishTrimmed):
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/dotnet-web-ubi-micro latest 51b29cdc96cb 3 seconds ago 57.4 MB
Выбираем базовые образы для приложений на .NET: минимум уязвимостей, максимум быстродействия