Вы двигаетесь со скоростью миллион миль в минуту, внедряя новые технологии, такие как контейнеры, бессерверные системы и Kubernetes, и автоматизируя все под солнцем. DevOps изменил то, как ваши команды создают, тестируют и развертывают приложения. Но в торопливом стремлении выпускать приложения быстрее и чаще безопасность часто остается в пыли.
Новые проблемы безопасности в облаке возникают с пугающей частотой, и традиционное тестирование безопасности просто не успевает за ними. Вам нужен способ интегрировать методы обеспечения безопасности на более ранних этапах жизненного цикла разработки. Именно здесь на помощь приходит безопасность со сдвигом влево.
Безопасность со сдвигом влево означает включение практик безопасности в рабочий процесс DevOps с самого начала. Вместо того чтобы браться за сканирование и тестирование после того, как приложение «готово», вы смещаетесь влево и интегрируете их на протяжении всей разработки. Это может включать в себя:
Сдвиг влево приводит к тому, что вопросы безопасности обсуждаются рано и часто. Вы включаете ее в жизненный цикл разработки, так что она перестает быть лишь размышлением перед запуском.
Возможно, вы думаете: «Я уже провожу сканирование во время конвейера. Разве этого не достаточно? Почему безопасность при сдвиге влево имеет такое большое значение? Есть несколько ключевых причин:
1. Устранение проблем на ранних стадиях обходится значительно дешевле.
Устранение уязвимостей безопасности в производстве обойдется значительно дороже, чем в разработке. Представьте себе, что вы можете устранить уязвимость SQL-инъекции во время проверки кода до того, как он попадет в среду хранения. Усилия и риски, связанные с этим, ничтожно малы по сравнению с реагированием на публично раскрытый эксплойт в производстве. Сместите тестирование безопасности влево и устраняйте целые классы дефектов до того, как они станут дорогостоящими.
2. Ваши релизы не выходят из графика
Когда вы оставляете тестирование безопасности на время перед запуском, любые уязвимости или сбои приводят к тому, что вы начинаете суетиться в последнюю минуту. Вам может потребоваться отложить выпуск релиза, чтобы исправить или перепроверить проблемы. Практика Shift-left предотвращает неожиданности в последнюю минуту, поэтому ваши команды могут выпускать релизы надежно и в срок.
3. Ваши разработчики создают более безопасный код
Разработчики имеют наибольший контроль над безопасностью приложений. Вооружите их навыками и обратной связью, чтобы сделать безопасное кодирование второй натурой. Переместив левую часть цикла планирования и разработки, они смогут устранять целые категории уязвимостей по умолчанию. Вся ваша кодовая база станет более надежной.
4. Вы снижаете риск
Чем раньше вы поймаете проблемы безопасности на этапе SDLC, тем меньший риск они представляют для вашей организации. Код с недостатками, который находится в репозиториях или конвейерах, гораздо менее рискован, чем тот же самый код в продакшене. Смещение влево сокращает окно уязвимости в процессе выпуска.
5. Облачные среды повышают риск
Ваша облачная инфраструктура создает целый набор новых рисков - неправильно настроенные ведра S3, утекающие данные, слишком разрешительные роли IAM, непропатченные вычислительные инстанции и так далее. Злоумышленники любят эксплуатировать ошибки в облаке не меньше, чем недостатки приложений. Смещение акцента влево на облачную безопасность за счет блокировки сред и шаблонов «инфраструктура как код» уменьшает эту значительно расширившуюся поверхность риска.
Если вы понимаете важность левостороннего подхода к безопасности, важно помнить, что впереди самая сложная работа... реальное осуществление организационных изменений. Вот несколько советов по преобразованию практики:
Пытаясь в одночасье перестроить весь SDLC, вы обречены на провал. Начните с малого - добавьте одну левостороннюю практику постоянного сканирования репозиториев кода на предмет уязвимостей в открытых источниках. Как только она приживется, добавьте еще одну. Важно не совершенствоваться, а двигаться вперед.
Собирайте данные и истории, демонстрирующие ценность левосторонней безопасности. Отслеживайте найденные дефекты и предотвращенные расходы. Отмечайте победы разработчиков, которые находят ошибки во время проверки кода. Публично поощряйте «рок-звезд» левостороннего сдвига. Цифры и истории вдохновляют на перемены.
Наказание разработчиков за внедрение уязвимостей и неудачные сборки только препятствует прозрачности в отношении ошибок. Вместо этого поощряйте их за использование методов безопасного кодирования - выделите время на соответствующее обучение и установите цели по KPI безопасности.
Требуйте проведения обзоров безопасности для новых технологий и фреймворков. Добавьте обязательные критерии безопасности в документацию по планированию проекта. Включите ее в демонстрационные ролики спринтов и ретроспективы. Интеграция процессов стимулирует последовательное поведение, а не оставляет все на усмотрение людей.
Да, тестирование со сдвигом влево приведет к увеличению количества дефектов и задержек на ранних этапах. Командам может показаться, что дополнительные критерии безопасности «тормозят» работу. Однако посмотрите на это в долгосрочной перспективе - такая обратная связь поможет впоследствии безопасно развернуть более устойчивый код в масштабе.
Мы много говорили о практиках в конвейерах и SDLC. Но не менее важно заблокировать облачную среду, в которой работают ваши приложения. Неправильная конфигурация облачной инфраструктуры, такой как Kubernetes, бессерверные функции и объектные хранилища, может привести к возникновению рисков безопасности, таких как дефекты на уровне кода. Вот несколько лучших практик работы в облаке:
Помните, что злоумышленники стремятся использовать неправильную конфигурацию облака в той же степени, что и недостатки на уровне кода. Обеспечьте жесткую блокировку инфраструктуры и кодовой базы.
Поначалу смещение акцента на безопасность влево может показаться некомфортным. Разработчикам придется думать о моделях угроз и уязвимостях в дополнение к требованиям к продукту. Релизы могут показаться «замедленными» из-за дополнительного тестирования. Однако придерживайтесь этих практик, чтобы добиться долгосрочных успехов в области информационной безопасности.
Команда Socket Research Team обнаружила вредоносный пакет Python под названием 'fabrice', который выдает себя за популярную библиотеку автоматизации SSH 'fabric' и крадет учетные данные AWS у ничего не подозревающих разработчиков.
Утечки данных стали регулярным явлением, в результате которого миллионы людей подвергаются риску раскрытия своих личных данных.
Хакеры атакуют машины под управлением Windows, используя технику конкатенации ZIP-файлов для доставки вредоносной полезной нагрузки в сжатых архивах без обнаружения решениями безопасности.