Написано Иваном Миленковичем, вице-президентом по технологиям управления рисками в регионе EMEA, Qualys
Большую часть последнего десятилетия мы были заняты комфортными фантазиями о безопасности и развитии. Если бы мы могли просто «сдвинуться влево» и заставить разработчиков взять на себя немного больше ответственности за кодирование, тестирование и развертывание инфраструктуры, а также за безопасность, цифровой мир стал бы более безопасным, быстрым и дешевым местом. Вместо этого фундаментальный конфликт между скоростью и безопасностью усугубился.
Почему это не удалось? Разработчики находятся под сильнейшим давлением. Классический треугольник управления проектами – быстро, хорошо, дешево; Выбери два – разорван на части.
Бизнес требует быстрого, хорошего, дешевого и безопасного. Когда дело доходит до дела, всегда побеждает «быстрее». Плюс мы возлагаем слишком большую когнитивную нагрузку на разработчиков, которые уже тонут.
Когда они решают использовать общедоступные образы контейнеров для ускорения разработки, они пытаются достичь своих целей, но при этом подвергаются потенциальному риску. Так как же нам понять, в чем заключается настоящая проблема, и затем работать над ее решением?
Требования бизнеса перевешивают рекомендации по безопасности
В индустрии безопасности широко распространено мнение, что разработчики ленивы или небрежны. Это абсолютно неправда. Разработчики не ленивы; Это перегруженные прагматичные профессионалы, которые реагируют на предложенные им стимулы. Если их бонус зависит от поставки функций к пятнице, а проверка безопасности занимает четыре часа и блокирует сборку, они найдут способ обойти проверку.
Предприятия требуют более быстрых результатов, что создало среду, в которой протоколы безопасности рассматриваются как препятствие производительности, а не как неотъемлемая часть проектирования. Когда инструменты безопасности работают шумно, медленно и отвлекают от рабочего процесса, они становятся помехой.
Однако это привело к тому, что организации потеряли контроль над тем, что на самом деле происходит в их среде. У нас есть конвейеры, которые автоматически развертывают код, инфраструктура, которая масштабируется вверх и вниз без вмешательства человека, и агенты ИИ, которые теперь могут писать и выполнять свои собственные сценарии.
В этом высокоскоростном автоматизированном хаосе мы относимся к публичным реестрам как к курируемым библиотекам, полагая, что, поскольку образ находится в Docker Hub, он должен быть безопасным. Но извлечь контейнер из общедоступного реестра, такого как Docker Hub, — это надежное решение.
Такие компании, как Docker, Amazon, Google и Microsoft, управляют общедоступными реестрами контейнеров, поэтому существует естественное предположение, что они безопасны.
Это убеждение ошибочно. К тому времени, когда образ контейнера попадает в конвейер развертывания, он уже является надежным артефактом, встроенным в приложение.
Платформа Forrester Wave™ для облачной защиты приложений 2026 года (CNAPP) обеспечивает объективный анализ облачной безопасности.
Узнайте, почему Qualys сегодня является лидером рынка.
прочитать информационный документ
34 000 проверок реальности изображений
Подразделение исследования угроз Qualys (TRU) недавно провело подробный анализ более 34 000 образов контейнеров, извлеченных из общедоступных репозиториев, чтобы увидеть, что на самом деле происходит под манифестом.
Из этого общего числа около 2500 изображений (около 7,3 процента выборки) были вредоносными. 70 процентов вредоносных изображений содержали программное обеспечение для майнинга криптовалют.
Кроме того, 42 процента изображений содержали более пяти секретов, которые можно было использовать для получения доступа к другим ресурсам или учетным записям. Сюда входят ценные элементы, такие как ключи доступа к AWS, токены API GitHub и учетные данные базы данных, встроенные непосредственно в слои изображений.
По нашему анализу, самые большие проблемы, связанные с вредоносными контейнерами, по-прежнему очень просты. Тайпсквоттинг — один из наиболее распространенных методов, которые злоумышленники используют для загрузки своих вредоносных контейнеров. Да, стандартный совет «проверить орфографию» необходим, но это также малоэнергичный ответ на проблему высокого риска.
Сказать разработчику «быть более осторожным» — это не стратегия безопасности. Хотя публичные реестры полезны для скорости, мы не должны позволять разработчикам вообще уклоняться от публичных реестров.
В зрелой среде каждое внешнее изображение должно быть проксировано через внутренний репозиторий артефактов, который действует как карантинная зона. Тем не менее, эта жажда скорости не собирается заканчиваться. Вместо этого нам нужно работать над тем, как помочь разработчикам двигаться быстрее, сохраняя при этом безопасность.
Это означает больше работы для команды, занимающейся инфраструктурой, но эта работа должна позволить разработчикам двигаться вперед быстрее и с меньшим риском.
сдвинуть вниз
Логика в том, что дешевле исправлять ошибки во время проектирования или кодирования, чем на производстве. Таким образом, перенос безопасности на более ранние этапы жизненного цикла разработки программного обеспечения (SDLC) должен снизить риск на более позднем этапе. Хотя теоретически это имеет смысл, разработчикам предлагается сканировать собственный код, проверять свои зависимости и управлять собственной инфраструктурой.
На самом деле мы только что перенесли боль вперед. Это требует от разработчиков управлять уязвимостями, усилением конфигурации, секретными идентификаторами, аудитом соответствия и т. д. Кроме того, этих разработчиков в первую очередь оценивают по скорости разработки новых функций.
Целью «Сдвига влево» было обеспечение безопасности союзников. Вместо этого проблема была переложена на IDE каждого разработчика. Чтобы решить эту проблему, нам нужно сделать безопасность по умолчанию в инфраструктуре, а не задумать ее заранее.
Это предполагает реальное сотрудничество между разработчиками и службами безопасности: разработчики должны понимать, чего они хотят достичь и что потребуется от того, что они создают, в то время как служба безопасности должна обходить эти требования, чтобы их можно было доставить безопасно. Обе команды несут ответственность, но им обеим приходится работать в том темпе, которого требует бизнес.
На практике мы можем создать «золотой путь» для разработчиков. Если они используют стандартные шаблоны, предварительно одобренные базовые образы и официальные конвейеры CI, безопасность бесплатна. Если они хотят пойти «по бездорожью» и создать что-то индивидуальное, им придется проделать дополнительную работу по проверке безопасности и ручной настройке.
Это также то, что должно быть встроено в бизнес с самого начала, чтобы безопасность и развитие представляли единый фронт вокруг затрат.
Такой подход способствует безопасному развертыванию сил, поскольку это путь наименьшего сопротивления. Это переносит ответственность вниз по стеку на уровень инфраструктуры, которым управляет специализированная команда разработчиков платформы. А если требуется что-то другое, эту работу можно выполнять совместно, чтобы гарантировать, что она будет выполнена правильно с первого раза, а не приведет к появлению новых проблем, которые необходимо исправить.
Например, вместо того, чтобы просить разработчика включить управление версиями для определенной корзины S3, команда платформы пишет политику, используя модуль Terraform, CrossPlane Composition или агент открытой политики, которая не позволяет корзине существовать без управления версиями. Разработчик буквально не может ошибиться.
Платформа автоматически исправляет это или отклоняет запрос. Аналогично, разработчикам не нужно забывать добавлять сканирование контейнеров в свой рабочий процесс: конвейер CI должен делать это автоматически. Входной контроллер должен отклонять несовместимые изображения до того, как они попадут в кластер. Разработчику не нужно знать, как работает сканирование, достаточно знать, что если он попытается внедрить критическую уязвимость, дверь будет заперта.
«Сдвиг вниз» также означает автоматизацию исправлений. Например, если в базовом образе обнаружена уязвимость, платформа должна автоматически сгенерировать запрос на его обновление. Если инструмент безопасности во время выполнения обнаруживает контейнер с неправильным поведением (например, создающий оболочку для сохранения), он НЕ ДОЛЖЕН просто отправлять предупреждение. Это должно уничтожить модуль и автономно отключить узел.
Вместо того, чтобы придерживаться существующих методов обеспечения безопасности и развития, нам необходимо реагировать на происходящее. Это может означать фундаментальное изменение методов работы внутри команд.
Если мы продолжим менталитет «сдвига влево», возлагая когнитивную нагрузку на разработчиков, мы потерпим неудачу. Мы их выжжем, и они обойдут наш контроль только для того, чтобы получить то, что нужно для бизнеса.
Вместо этого служба безопасности должна активно внедрять и поддерживать подходящие для бизнеса платформы, автоматически обеспечивая их безопасность.
Спонсор и автор Qualys.
