Более десяти лет индустрия пыталась повысить безопасность ПО, приближая её к разработчикам. Мы внедрили сканеры в CI, добавили проверки безопасности в pull request и требовали от команд быстрее реагировать на бесконечный поток уязвимостей. Однако коренные проблемы так и не были решены.
Дело не в том, что разработчики пренебрегают безопасностью. Проблема в том, что мы пытаемся чинить её на периферии, вместо того чтобы исправить фундамент. Жестко сконфигурированные (hardened) образы контейнеров меняют эту динамику: они сокращают поверхность атаки и устраняют основную массу незначительного шума по безопасности ещё до того, как он достигнет команд разработки.
Безопасность терпит крах, когда превращается в шум
Большинству разработчиков небезразлична безопасность ПО. Но их не волнует показная активность в этой сфере.
То, как мы сегодня работаем с уязвимостями, особенно CVE, часто создает для команд устойчивый поток низкоприоритетных задач. Алерты сыплются непрерывно. Многие из них технически валидны, но практически незначимы. Другие требуют исправления компонентов, которые разработчики не выбирали и по сути не контролируют. Со временем это превращает безопасность в фоновый шум.
Когда это происходит, система уже дала сбой. Разработчики вынуждены переключать контекст, команды тратят время на обсуждение критичности, а реальные риски тонут в проблемах, не имеющих значения. Это не проблема мотивации, а проблема архитектуры системы.
Индустрия ответила попыткой «сдвига влево» (shift left) – внедрения безопасности на ранние этапы разработки. На практике это часто означало перекладывание дополнительной работы на разработчиков без предоставления им более надежных базовых средств и фундамента. Результатом стало увеличение рутины, алертов и причин игнорировать их.
Сдвиг влево был верным инстинктом, но ошибочным исполнением. Цель не в том, чтобы заставить разработчиков делать больше работы по безопасности. Она в том, чтобы сделать безопасный выбор простым и очевидным по умолчанию, позволяя разработчикам добиваться лучших результатов с меньшими усилиями.
Почему большие образы стали стандартом
Чтобы понять, как мы дошли до жизни такой, нужно честно признать, почему большинство команд начинали с больших, универсальных базовых образов.
Когда Docker запустился в 2013 году, контейнеры были в новинку. Разработчики тянулись к знакомому: полноценным дистрибутивам Linux и привычным средам Debian или Ubuntu со всеми необходимыми инструментами отладки.
Большие образы, в которых есть всё, были разумным выбором по умолчанию. Такой подход оптимизирован под простоту и гибкость. Когда всё, что может понадобиться, уже под рукой, уменьшается трение при разработке, сборки реже падают, упрощается отладка, а неизвестные зависимости реже преподносят сюрпризы.
Долгое время создание чего-то более безопасного требовало реальных вложений. Командам была нужна платформенная группа для проектирования, закалки и постоянной поддержки собственных базовых образов. Эта работа конкурировала за приоритет с функциями продукта и инфраструктурными задачами. Большинство организаций так и не сделали этот выбор, и их решение было понятным.
В итоге индустрия сошлась на знакомом паттерне: начать с большого образа, быстрее выпустить продукт в краткосрочной перспективе, а с последствиями разбираться потом.
Эти последствия накапливаются. Большие образы резко увеличивают поверхность атаки, накапливают устаревшие зависимости и генерируют бесконечные CVE, которые разработчикам приходится сортировать спустя долгое время после первоначального выбора. То, что начиналось как удобство, медленно превращается в постоянный тормоз для безопасности и разработки.
Надежная основа улучшает пользовательский опыт
Широко распространено мнение, что лучшая безопасность требует ухудшения пользовательского опыта. На практике часто верно обратное.
Старт с безопасной, специализированной основы уменьшает сложность, а не добавляет ее. Меньшие образы содержат меньше пакетов, а значит – меньше уязвимостей и алертов. Разработчики тратят меньше времени на погоню за низкоприоритетными CVE и больше – на создание продукта.
Ключевой момент в том, что безопасность встроена в сам фундамент. Состав образа явный и воспроизводимый. Метаданные цепочки поставок (подписи, SBOM, происхождение) являются частью образа по умолчанию, а не дополнительными шагами, которые разработчикам нужно связывать самим. При этом такие основы легко и безопасно кастомизировать. Команды могут расширять или изменять свои образы, не нарушая их защищенность, благодаря предсказуемой слоистой структуре и поддерживаемым паттернам настройки. Это устраняет целые категории скрытых зависимостей и рутины, которые иначе ложились бы на отдельные команды.
Есть и ощутимые выгоды в производительности. Меньшие образы быстрее загружаются, собираются и развертываются. В крупных средах эти преимущества быстро накапливаются.
Важно, что это не требует жертвовать гибкостью. Разработчики по-прежнему могут использовать богатые среды сборки и знакомые инструменты, одновременно поставляя в продакшн минимальные, защищенные образы. Это редкий случай, когда повышение безопасности напрямую улучшает пользовательский опыт. Компромисс, с которым мы мирились годами, не неизбежен.
Что меняется, когда надежная основа становится стандартом
Когда безопасные фундаменты и жестко сконфигурированные образы становятся отправной точкой по умолчанию, система начинает вести себя иначе. Разработчики продолжают использовать те же привычные рабочие процессы Docker. Разница лишь в том, с какой базы они стартуют.
Усиление безопасности, установка патчей и гигиена цепочки поставок обрабатываются один раз в фундаменте, а не повторяются для каждого сервиса. Безопасные основы не ограничиваются базовыми образами ОС. Те же принципы применимы к ПО, на котором команды строят свои приложения: базам данных, средам выполнения и распространенным сервисам. Старт с жестко сконфигурированного образа MySQL или приложения снимает целый класс задач по безопасности и поддержке еще до того, как написана первая строка кода.
Именно для решения этой проблемы созданы Docker Hardened Images. Единые принципы защиты последовательно применяются к широко используемым образам контейнеров с открытым исходным кодом, не ограничиваясь слоем ОС, чтобы команды могли начинать с безопасных настроек по умолчанию там, где реально начинается их приложение. Цель — не внедрить еще один рабочий процесс или инструмент безопасности, а дать разработчикам более качественные строительные блокы с первого дня.
Поскольку фундамент поддерживается экспертами, команды сталкиваются с меньшим количеством сбоев, экстренных пересборок и общеорганизационной паники при появлении широко эксплуатируемой уязвимости. Команды безопасности могут сосредоточиться на внедрении и оценке состояния, вместо того чтобы просить десятки команд независимо решать одну и ту же проблему.
Результат — меньше рутины и больше времени на работу над продуктом. Это выигрыш для разработчиков, команд безопасности и бизнеса.
Стройте на лучших стандартах
Годами мы пытались улучшить безопасность, прося разработчиков делать больше: устанавливать патчи быстрее, реагировать на большее количество алертов, осваивать новые инструменты. Этот подход не масштабируется.
Безопасность масштабируется тогда, когда сильны стандарты по умолчанию. Когда фундаменты спроектированы безопасно и поддерживаются с течением времени. Когда разработчики не вынуждены постоянно компенсировать решения, принятые далеко под их кодом.
Если мы хотим лучших результатов в безопасности без замедления команд, мы должны начинать там, где ПО реально начинается. Это требует безопасных фундаментов, таких как жестко сконфигурированные образы, которые безопасны по умолчанию. С лучшим фундаментом безопасность становится тише, разработка — плавнее, и вся система работает так, как должна.
Вот к какой планке мы должны стремиться.