Охота за образами контейнеров с нулевым CVE

1770752750
2026-02-10 19:33:00

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

Мы все хотим, чтобы в наших образах контейнеров не было распространенных уязвимостей и уязвимостей (CVE), и создание таких образов само по себе стало бизнесом. То, что началось как агрессивная позиция «сдвига влево», стало базовым ожиданием для контейнерных рабочих нагрузок. Но как лучше всего создать эти безопасные изображения?

Цепочкаодин из ведущих поставщиков образов контейнеров с нулевым CVE, использует свое новое программное обеспечение Factory 2.0 и подход с открытым исходным кодом DriftlessAF для восстановления контейнеров и библиотек непосредственно из исходного кода при обнаружении изменений в исходном коде. Каждый манифест сборки контейнера представляет собой воспроизводимые выходные данные системы, охватывающие начальные сборки, перестройки на основе зависимостей и уязвимостей, изменения инструментов, а также сгенерированные SBOM и сигнатуры, и все это согласовано с состоянием безопасности по умолчанию.

Другие построители образов с нулевым CVE, такие как Докер с его Защищенные образы Docker (DHI)предложить уменьшенную поверхность атаки, настройки по умолчанию без полномочий root, SBOM и криптографическое происхождение, а также использовать другой подход. Они связаны с исходными версиями Alpine Linux и Debian Linux.

Сэм Катцен, менеджер по маркетингу продуктов Chainguard, утверждает в недавнем интервью изданию Новый стек что «длинные цепочки зависимостей и более медленные циклы выпуска разработчиков исходных дистрибутивов […] просто не может идти в ногу с сегодняшним взрывным ростом числа зарегистрированных уязвимостей. Поскольку эти поставщики полагаются на вышестоящие дистрибутивы для исправления и восстановления, существует неизбежная задержка между раскрытием информации и исправлением. Это ставит поставщиков, которые полагаются на такие дистрибутивы, как Debian или Alpine, в затруднительное положение: они наследуют уязвимости, которые они не создавали и которые не могут легко контролировать».

Когда не-DSA недостаточно

Копнув глубже, Катцен утверждает, что, поскольку DHI построен непосредственно на Debian, его образы наследуют набор пакетов Debian, уровень безопасности и график выпуска. На практике многие записи Vulnerability Exploitability eXchange (VEX) DHI — машиночитаемые документы, которые сообщают сканерам, действительно ли CVE влияет на данный образ — эффективно отражают записи Debian. собственные консультации по безопасности (DSA) состояние сортировки.

Команда безопасности Debian использует флаг «no-DSA» в своем трекере для проблем, которые не требуют немедленного DSA и перестройки вне цикла. Такие решения часто принимаются потому, что проблемы безопасности считаются незначительными или слишком сложными для использования, чтобы их можно было немедленно устранить. В документации Debian DSA «no-DSA» явно описывается как рекомендательный механизм определения приоритетов.. Точнее, «такие проблемы, как правило, не остаются нерешенными, но их все равно можно исправить с помощью точечного обновления или путем объединения исправления с будущим обновлением для более серьезной проблемы».

Это может быть достаточно хорошо для Debian, но Катцен считает, что для вас этого может быть недостаточно. Правда, по его словам, «многие из CVE, помеченных как no-DSA, совершенно непригодны для использования и их разумно решать таким образом». Тем не менее, рассмотрение этого флага сортировки как доказательства того, что пакет «не затронут», смешивает определение приоритетов риска с отсутствием уязвимостей и может ввести в заблуждение последующих потребителей, которые полагаются на сканеры, подключенные к VEX.

Это серьезная проблема, когда ведущие разработчики уже объединили исправления, но эти исправления еще не попали в Debian и, следовательно, еще не в DHI. В частности, Катцен указывает на три серьезные уязвимости CVE, которые еще не были обнаружены и исправлены в Debian.

• CVE-2026-0861: Этот недостаток glibc в семействе memalign может привести к переполнению целых чисел и повреждению кучи, и ему присвоен ВЫСОКИЙ рейтинг (8,4) в Национальной базе данных уязвимостей (NVD). В настоящее время Debian перечисляет несколько выпусков, в том числе bookworm и trixie, как уязвимые, с исправлением только в новой серии «вилок». Несмотря на это, запись DHI VEX, связанная с классификацией Debian «no-DSA», помечает затронутые образы как «не затронутые», ссылаясь на то, что уязвимый код не может контролироваться злоумышленником, при этом продолжая поставлять непропатченную Debian glibc. Поскольку многие образы DHI, такие как среды выполнения языков и базы данных, зависят от glibc, этот статус эффективно подавляет настоящую, неисправленную CVE из выходных данных сканера.
• CVE-2026-0915: Отдельная проблема glibc, которая может привести к утечке содержимого памяти, также имеет ВЫСОКИЙ рейтинг (7,5) от NVD и аналогично помечается как «no-DSA» в Debian, что сигнализирует о решении отложить исправление до обычного выпуска. Здесь также данные VEX от DHI соответствуют приоритетам Debian, помечая образы как «не затронутые», даже несмотря на то, что базовая версия пакета Debian остается в списке уязвимых и никакие последующие исправления не применялись. Пока Debian не перестроит или нижестоящий поставщик не выберет восходящий коммит, образы, встраивающие эту сборку glibc, будут технически затронуты, и сканеры должны отражать это состояние.
• CVE-2025-6141 (ncurses): эта ошибка ncurses допускает переполнение буфера стека при обработке записей termcap, требует локального доступа и имеет низкий уровень серьезности. Эта ошибка была исправлена в исходной версии ncurses 6.5-20250329 в марте 2025 года. Спустя несколько месяцев Debian все еще не отправил исправленный пакет для всех соответствующих выпусков и пометил CVE как «no-DSA», отложив исправление до своего стандартного цикла. В истории VEX компании DHI по крайней мере для одного образа на основе Debian сначала была записана проблема как «в стадии расследования», в то время как она «ожидает исправления исходной версии», а затем статус был изменен на «не затронуто» на основании тега Debian no-DSA – опять же без доказательств того, что исправленная сборка ncurses была интегрирована в образ.

Поэтому, утверждает Катцен, “уязвимость существует в DHI, и исправление доступно в исходной версии, но исправление не было перенесено в DHI. CVE автоматически подавляется при сканировании с помощью Докер Скаут и за счет использования документа VEX в других сканерах».

Достаточно ли закаленных изображений?

С точки зрения Chainguard это означает, что поставщики, создающие «защищенные» образы поверх универсальных дистрибутивов сообщества, могут оказаться в ловушке между прозрачностью и достижением почти нулевого количества CVE. Выбор исправлений перед Debian подтолкнет Docker и других, кто использует аналогичную частоту, к поддержанию фактической вилки со всеми вытекающими отсюда головными болями по долгосрочному обслуживанию и регрессу.

Катцен утверждает, что это перекладывает нагрузку на клиентов и их инструменты. По мере того, как VEX становится все более глубоко интегрированным в сканеры и рабочие процессы обеспечения соответствия, чрезмерно агрессивное подавление «неудобных» CVE подрывает саму перспективу получения нормализованных, машиночитаемых данных об уязвимостях.

Затем он, конечно же, хвалит модель Chainguard, в которой сортировку и исправление CVE можно выполнять непосредственно от источника к образу, не дожидаясь расписания вышестоящего дистрибутива. Этот комплексный контроль лежит в основе каталога, состоящего из более чем 2000 минимальных изображений, которые постоянно перестраиваются для поддержания состояния с нулевым CVE, сохраняя при этом видимость цепочки поставок, SBOM и явную обработку CVE.

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

Но насколько важны CVE?

Но эти дебаты также поднимают более фундаментальный вопрос: является ли проблема в самой системе противодействия насильственному экстремизму?

Некоторые охранные организации и компании, такие как Альянс облачной безопасности и Решение для службы безопасностиутверждать, что CVE не зависят от окружающей среды. Они говорят, что «уязвимость существует», но не говорят, существует ли она. опасно для вашего развертывания.

Кроме того, согласно одному исследованию, около трети CVE недействительны. Доктор Арам Овсепян, соучредитель и генеральный директор охранного бизнеса Кодификационныйотмечает: «Для специалистов по безопасности запись о CVE также является ценным дополнением к резюме. явная мотивация генерировать больше CVE, даже если их воздействие может быть сомнительным. Более того, в систему можно играть, и создать CVE ради этого не составляет особого труда». Как недавно отметил создатель cURL Дэниел Стенберг, слишком легко использовать ИИ для создания фиктивных отчетов о безопасности.

Другими словами, как комментирует Овсепян, “CVE не бесполезны. Они являются ценным вкладом. Но они никогда не должны быть основой всей стратегии AppSec. Нам нужно начинать с общего понимания риска, основанного на моделировании угроз и контекстной сортировке. Панели мониторинга уязвимостей могут помочь, но только если интерпретировать их через научную призму”.

Короче говоря, есть что сказать по поводу обоих подходов, и одних показателей CVE недостаточно, чтобы быть уверенным в полной безопасности ваших изображений. Ноль имеет значение, но нельзя предполагать, что ноль означает безопасность. Никто никогда не говорил, что обеспечение безопасности – это легко. Эти новые изображения помогают, но они не идеальны.

YOUTUBE.COM/THENEWSTACK

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

ПОДПИСАТЬСЯ

Группа создана с помощью Sketch.

Стивен Дж. Воан-Николс, он же sjvn, писал о технологиях и технологическом бизнесе с тех пор, как CP/M-80 была новейшей операционной системой для ПК, скорость 300 бит/с — высокоскоростное подключение к Интернету, WordStar — современный текстовый процессор, и он нам понравился.

Узнайте больше от Стивена Дж. Воана-Николса.
#Охота #за #образами #контейнеров #нулевым #CVE