Что такое DevSecOps и концепция Shift-left

DevSecOps — актуальное направление в разработке, благодаря которому организации могут быстро создавать и выпускать защищенные приложения. Этот подход помогает обеспечивать безопасность на всех этапах цикла разработки и доставки программного обеспечения и соблюдать требования ИБ.

Из серии статей вы узнаете об основных этапах DevSecOps-пайплайна, автоматизированных проверках безопасности при разработке ПО, бесплатных и опенсорс-инструментах. Также вы найдёте советы, которые помогут раньше обнаруживать уязвимости и улучшать безопасность приложения.

Эта статья будет полезна руководителям и сотрудникам отделов информационной безопасности, разработки и DevOps-командам. Она поможет оценить зрелость вашего DevSecOps-пайплайна, разработать дорожную карту его развития, выбрать правильные инструменты для каждой задачи и просто лучше понять, как управлять проектами в соответствии с философией DevSecOps.

Концепция Shift-leftКонцепция Shift-left

Главная цель методологии DevSecOps — внедрение автоматизированных проверок безопасности в DevOps-пайплайн, то есть в сам процесс разработки ПО.

До недавнего времени специалисты по информационной безопасности проводили проверки уже после завершения процесса разработки. Такой подход неэффективен — если в процессе тестирования безопасности обнаруживаются ошибки, приходится начинать весь цикл разработки заново. Это долго и дорого.

Посмотрите схему ниже. На ней видно, что стоимость исправления ошибок растёт с каждым этапом.

Исправить проблемы с безопасностью, которые обнаружились в процессе разработки и функционального тестирования, почти ничего не стоит. Все нужные изменения можно сразу внести в исходный код и отправить на повторную проверку.

Исправить проблемы на этапе сборки артефактов дороже минимум в два раза. Придётся вносить изменения в процесс сборки, например редактировать Dockerfile. А это значит, что потребуется помощь DevOps-инженеров.

Если ошибка обнаружилась во время интеграционного тестирования, её исправление будет в десятки раз дороже. Ведь в этом случае придётся перезапускать цикл разработки заново и привлекать разработчиков, DevOps-инженеров и тестировщиков.

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

Отсюда главный вывод — проверки безопасности нужно выполнять как можно раньше. Если представить это визуально — перенести их в левую сторону пайплайна. Это и есть концепция Shift-left, о которой так любят говорить безопасники.

Структура DevSecOps-пайплайнаСтруктура DevSecOps-пайплайна

DevSecOps-пайплайн — это автоматизированная цепочка процессов и инструментов, которые позволяют создавать, тестировать и доставлять приложения в производственную среду, а также обеспечивать их безопасность на каждом этапе.

На рисунке выше изображена структура DevSecOps-пайплайна со всеми основными фазами проверки безопасности. Несколько слов о каждой из них.

Pre-commit — проверка безопасности исходного кода до того, как разработчик закоммитит код в систему контроля версий. Проверка позволяет обнаружить незашифрованную конфиденциальную информацию: пароли или API-ключи.

Pre-build — проверка безопасности исходного кода после того, как он попал в систему контроля версий. Инструменты выполняют статический анализ исходного кода и его зависимостей, чтобы обнаружить распространённые уязвимости, например из списка OWASP Top Ten.

Post-build — проверка безопасности артефакта, собранного из исходного кода, например Docker-файла, RPM-пакета или JAR-архива. Инструменты анализируют окружение и зависимости приложения, отыскивая устаревшие версии пакетов и библиотек, уже имеющих исправления в более новых версиях.

Test-time — проверка безопасности приложения, которое запущено из собранного артефакта. Инструменты в этой фазе пытаются «сломать» приложение, имитируя действия злоумышленников.

Post-deploy — проверка безопасности приложения после развёртывания в production-среде. Инструменты в режиме реального времени мониторят открытые реестры известных уязвимостей и отправляют уведомление, обнаружив угрозу для приложения.

Что в итогеЧто в итоге

В первой статье мы рассказали о том, что сдвигать проверки безопасности в левую часть пайплайна выгоднее для компании, чем проводить проверку после выпуска продукта. Мы также рассмотрели структуру DevSecOps-пайплайна со всеми основными фазами проверки безопасности.

Во второй и третьей статье мы расскажем подробнее, что из себя представляют проверки на каждом этапе DevSecOps-пайплайна и с помощью каких инструментов их проводят.