Контейнеры стали сантехникой современной инженерии. Они повсюду, молча питают приложения, трубопроводы CI/CD и целую нативную инфраструктуру облаков. Но, как и сантехника в вашем доме, большинство инженеров не думают о том, как они работают — пока что -то не станет катастрофически неправильным. Простота вытягивания публичного имиджа из Docker Hub или другого реестра сделала контейнеры строительным блоком по умолчанию для современных приложений. Тем не менее, эта абстракция содержит значительную стоимость: полное отсутствие видимости в базовых рисках безопасности.
Проблема двояка: общеотраслевая разрыв в основе знаний и подавляющий поток уязвимостей. Большинство инженеров сегодня работают на уровне приложения и никогда не нужно было понять, что происходит под капюшоном. По мере того, как ИИ ускоряет разработку и абстрагульную абстрактуру, число инженеров с глубоким системным опытом продолжает сокращаться. Это создает мир, в котором, когда возникают проблемы безопасности контейнеров, которые не имеют непосредственных и очевидных исправлений, понимание основной водопроводной сантегии для их исправления стало серьезной проблемой для организаций, управляющих контейнерами в масштабе.
Этот пост исследует, почему безопасность контейнеров стала растущим источником риска и сложности в современной инженерии, но не должно быть. Мы рассмотрим препятствия, с которыми сталкиваются организации, пытаясь отслеживать, сортировать и исправить уязвимости, почему текущие подходы терпят неудачу, и что можно сделать, чтобы выйти за рамки бесконечного исправления и пожаротушения.
Бесконечная уязвимость лавина
Безопасность контейнеров сегодня сломана, потому что она заставляет организации участвовать в постоянной реактивной игре Whack-A-Mole. Это начинается с одного базового изображения. Это изображение развертывается на тысячах экземпляров, каждый из которых поддерживает свой собственный набор приложений — каждый из которых является тонкой стопкой зависимостей, конфигураций и причуд.
Затем CVE попадает.
Эта уязвимость не только влияет на один контейнер — теперь он умножается во всех экземплярах, используя этот базовый изображение. Команды безопасности пытаются отслеживать, какие рабочие нагрузки уязвимы, какие приложения подвергаются риску, и есть ли даже жизнеспособное исправление. И с каждым новым CVE, который падает, список отслеживаемых уязвимостей растет в геометрической прогрессии.
Результат?
Бесконечный кошмар сортировки, где команды тонут в долгах безопасности, вынуждены утомить цикл исправления, разрушения и пожарной торговли.
Возьмите недавнюю уязвимость CVE-2024-10963 в Libpam. Недостаток механизмов контроля доступа позволил злоумышленникам с корневыми привилегиями обходить локальные политики безопасности с помощью подготовки имени хоста. Несмотря на высокий рейтинг тяжести (CVSS 7.4), некоторые основные распределения Linux оставались уязвимыми через несколько недель после раскрытия. Команды безопасности, полагаемые на эти распределения, застряли в подвешенном состоянии, ожидая пятна вверх по течению при воздействии потенциальных атак. Это ежедневная реальность управления безопасности контейнеров: постоянная пожаротушения, непредсказуемая доступность патча и бесконечное отставание уязвимостей.
Почему текущие подходы терпят неудачу
Поиск уязвимости безопасности — это только начало кошмара. Настоящий хаос начинается, когда команды пытаются исправить его. Часто доступно исправление, но применение его не так просто, как заменять один пакет. Вместо этого это требует обновления всей ОС или переключения на новую версию критической зависимости.
С тысячами контейнеров в производстве, каждый из которых связан с конкретными конфигурациями и требованиями применения, это становится игрой в Jenga, где один неправильный ход может снизить целые услуги. Организации попытались решить эти проблемы с различными платформами безопасности, от традиционных решений сканеров уязвимости до новых решений ASPM (управление положениями безопасности приложений). Но эти инструменты, будучи полезными в отслеживании уязвимостей, не решают проблему с корнем: исправление их. Большинство инструментов сканирования генерируют списки сортировки, которые быстро становятся ошеломляющими. Когда базовое изображение обнаруживает новую уязвимость, команды безопасности должны спросить себя:
- Есть доступное исправление?
- Если это так, требуется ли это обновление ОС или значительных зависимостей?
- Применяет ли применение Fix Break другие приложения?
- Если исправление не существует, какие смягчения можно применять?
Хуже того, многие из этих патчей приземляются в будущих выпусках ОС, оставляя команды с двумя одинаково плохими вариантами: дождитесь исходного исправления и оставайтесь выставленными, или рискуйте разрушить производство. И этот цикл никогда не останавливается — новые уязвимости возникают каждую неделю, и каждое «исправление» угрожает создать столько же хаоса, сколько и сама уязвимость.
Они либо должны принять риск, дождаться исходного исправления, которое может занять недели или месяцы, либо попытаться исправить проблему сами — процесс, который требует глубокого опыта Linux и тщательного тестирования. Это приводит к узким местам безопасности, где команды вынуждены выбирать между безопасностью и стабильностью.
Автоматизируйте все вещи безопасности!
Реальность безопасности контейнеров сегодня заключается в том, что большинство команд начинают уязвимы по умолчанию. Общественные базовые изображения раздуваются ненужными зависимостями, пронизаны известными CVE и обновлены непредсказуемыми графиками. Даже когда команды активно отслеживают уязвимости, они часто застряли в ожидании исходных исправлений, которые могут никогда не прибыть или вынуждены обновлять полные обновления ОС, которые вводят больший риск, чем они решают. Есть альтернатива: модель безопасности, которая не полагается на распределения, чтобы не отставать.
Непосредственно применяя патчи, при необходимости обращается обратно, и восстанавливая изображения с точностью, организации могут освободиться от бесконечного цикла патч-и-хранения. Вместо того, чтобы реагировать на проблемы безопасности после того, как они нарушают операции, команды могут поддерживать закаленные изображения с самого начала без ущерба для стабильности или скорости разработчика.
Вот где появляются новые решения, такие как наш каталог изображений, ориентированные на сообщество, вступают в игру. Вместо того, чтобы полагаться на патчи вверх по течению или ждать следующего цикла распределения, это возможно:
- Обеспечить немедленные патчи Для критических уязвимостей, в том числе тех, у кого нет исходного иска.
- Защиты безопасности Для существующих версий, поэтому командам не нужно обновлять целые распределения.
- Восстановление базовых изображений с минимальными изменениями, чтобы убедиться, что исправления применяются без введения нарушающих изменений.
- Автоматизируйте развертывание исправленных изображенийсокращение времени воздействия уязвимости от недель до часов.
Этот подход резко уменьшает отставание уязвимости, мешая его экспоненциально расти с каждым новым CVE. Систематически исправляя известные уязвимости до того, как они когда -либо достигнут производства, безопасности и DevOps, исключают большую часть шума, который переполняет традиционные рабочие процессы управления уязвимостью.
Вместо того, чтобы утонуть в неуправляемой очереди вопросов — большинство из которых уже имеют исправления — разработчики и группы безопасности могут сосредоточить свое внимание на уязвимости, которые не имеют четких путей восстановления, что приоритет фактическому риску, а не теряется в бесконечном цикле сортировки. Это приводит к обеспечению безопасности, которая является сильнее и устойчивой, что позволяет командам исправлять угрозы в разумных контролируемых темпах.
Контейнеры должны быть невидимыми — пока это не важно
Текущее состояние безопасности с открытым исходным кодом и контейнерами неустойчиво. В связи с тем, что уязвимости, возникающие быстрее, чем организации могут их исправить, и растущий разрыв в навыках в основе системной инженерии, отрасль направляется к кризису неуправляемого долга по обеспечению безопасности. Единственный жизнеспособный путь — это переосмыслить, как обрабатывается безопасность контейнеров, переходя из реактивного исправления к бесшовному автоматическому исправлению.
Безопасность должна быть как сантехника: невидимая, когда все работает, но способен к немедленному ответу, когда что -то пойдет не так. Интегрируя превентивную безопасность в жизненный цикл контейнера — обеспечение того, чтобы базовые изображения были исправлены до того, как уязвимости станут кризисами — мы, наконец, можем начать разбивать цикл бесконечного пожара и переместить управление безопасностью нашего контейнера с реактивного к проактивному.
Вопрос больше не в том, если система сломана. Тем не менее, готовы ли мы освободиться от бесконечной сортировки и переосмыслить управление уязвимыми контейнерами с нуля.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Бенджи Калман, вице-президент по технике и соучредителям Root, имеет более чем десятилетие опыта в области исследования и строительства в области кибербезопасности и Devtools. Выпускники 8200, специализируясь на кибер -операциях, Бенджи был ранним столяром Snyk, где … Подробнее от Бенджи Калмана
