Компании часто начинают переход к DevSecOps с внедрения новых инструментов. Однако одних технических средств недостаточно: основные сложности связаны с перестройкой процессов, распределением ответственности и взаимодействием между техническими инженерами и экспертами по информационной безопасности.
При высоком темпе работы проверять все изменения перед выпуском продукта становится все труднее. В результате требования DevSecOps- и AppSec-специалистов начинают восприниматься как причина задержек релизов, уязвимости обнаруживают слишком поздно, а стоимость их устранения растет. Руководитель отдела консалтинга безопасной разработки компании «Бастион» Артем Пузанков рассказывает, почему классический подход к управлению рисками больше не соответствует современным практикам и как внедрить DevSecOps без конфликта между техническими командами.
Почему традиционных подходов к безопасности уже недостаточно
Ранее поиск уязвимостей в разрабатываемом ПО проводился на финальном этапе работы. Такой метод был эффективен, когда новые версии выходили раз в несколько месяцев: организация успевала выполнить проверки, найти критичные уязвимости и устранить их до ввода продукта в промышленную эксплуатацию.
Сегодня темп разработки заметно ускорился. Инженеры постоянно вносят изменения в код, используют автоматизированные пайплайны, микросервисы и облачные среды. Обновления могут публиковаться ежечасно, поэтому полноценный ручной аудит становится слишком долгим и замедляет работу команды.
При этом сложности с безопасностью могут появляться не только в самом приложении. Учитывать нужно и другие элементы ИТ-среды: контейнеры, сторонние библиотеки, конфигурации Kubernetes, облачные сервисы, API-интеграции и CI/CD-пайплайны. Если оценивать продукт исключительно перед выпуском, часть таких уязвимостей удастся заметить слишком поздно — к этому моменту уже завершится несколько циклов разработки, и устранение дефектов будет заметно дольше и дороже.
Контроль безопасности дополнительно усложняет распространение ИИ-инструментов, которые еще сильнее ускоряют создание кода: то, на что раньше уходили часы, теперь можно написать за минуты. В результате за тот же промежуток времени объем изменений растет, а вместе с ним увеличивается нагрузка на DevSecOps- и AppSec‑специалистов. Если подключать их только на финальном этапе, перед релизом придется разбирать весь накопившийся массив обновлений.
В DevSecOps контроль рисков встраивают в сам процесс: система автоматически анализирует новые версии по мере внесения правок, а найденные уязвимости исправляют на ранних стадиях. Поэтому они не копятся до итогового аудита, а их устранение распределяется по всему циклу разработки.
Какие организационные риски возникают при внедрении DevSecOps
DevSecOps нередко сводят к набору решений, которые достаточно просто добавить в существующую ИТ-инфраструктуру. Однако сами по себе они не дают нужного эффекта. Сначала техническим командам нужно определить зоны ответственности и договориться, как действовать при обнаружении рисков.
Одним из главных источников непонимания могут стать разные приоритеты специалистов. Программистам важно внедрять новые функции в срок, а экспертам по безопасности — предотвращать появление ИБ-угроз. Когда требования DevSecOps- и AppSec‑специалистов превращаются в дополнительную проверку перед выпуском и воспринимаются как очередное ограничение, это приводит к конфликтам. Избежать таких ситуаций помогают заранее установленные правила: какие уязвимости блокируют релиз, какие из них при этом допускается исправить позже и кто может согласовать исключение из заданных условий.
Следующий барьер при переходе к DevSecOps — отсутствие единых инженерных процессов. В крупных компаниях отдельные группы специалистов могут по-разному управлять репозиториями, организовывать CI/CD-пайплайны и жизненный цикл приложений. Из-за этого типовые механизмы контроля трудно встроить в повседневную работу: сначала необходимо унифицировать базовые практики и договориться об общих стандартах.
Сложности могут возникнуть и после подключения автоматических проверок. При внедрении инструментов анализа кода, сторонних библиотек, контейнеров и инфраструктуры компания начинает получать сотни, а иногда и тысячи новых срабатываний. Если процесс разбора результатов заранее не определен, а найденные уязвимости не расставлены по приоритетам, исправление находок превращается в хаос без понятного порядка действий.
Отдельный риск — нехватка квалифицированных специалистов, хорошо понимающих жизненный цикл создания программного обеспечения и требования к защите продуктов. ИБ‑команды не всегда глубоко погружены в CI/CD, контейнеризацию и облачные платформы. Инженеры, наоборот, могут не учитывать особенности безопасного проектирования и модели угроз. В результате обе стороны говорят на разных профессиональных языках.
Во многих компаниях сложности создают и существующие устаревшие системы, которые невозможно быстро адаптировать под современные практики разработки ПО. Кроме того, не всегда заранее определена ответственность за устранение найденных рисков. Если не зафиксировано, кто отвечает за каждый отдельный шаг в этом процессе, дальнейшая работа превращается в постоянные споры между подразделениями.
Какие специалисты нужны для DevSecOps
DevSecOps меняет привычный подход к реализации продуктов: вопросы безопасности входят в задачи инженеров, а ИБ-специалисты глубже включаются в процессы разработки ПО. Для технической команды необходимо понимание принципов защищенного программирования. Им важно разбираться в распространенных типах уязвимостей, уметь корректно настраивать аутентификацию, авторизацию и обработку пользовательских данных, а также самостоятельно интерпретировать результаты автоматических проверок.
Для DevOps- и SRE-инженеров одной из основных частей работы становится обеспечение безопасности ИТ-инфраструктуры. В их повседневные задачи входят контроль секретов — паролей, токенов, API-ключей и других учетных данных, поддержание устойчивости микросервисной архитектуры и CI/CD-процессов и администрирование Kubernetes.
От специалистов по AppSec и DevSecOps требуется экспертиза в области уязвимостей и защитных механизмов, а также понимание специфики разработки. Им необходимо владеть навыками работы с CI/CD, контейнерными платформами, облачной средой и помогать инженерам встраивать инструменты безопасности в существующий конвейер поставки ПО.
Важную роль во многих организациях начинают играть Security Champion или AppSec Business Partner внутри технической команды. Чаще всего это эксперт, который хорошо знает требования ИБ, сопровождает программистов при разборе результатов анализа и выступает связующим звеном между продуктовой группой и специалистами по информационной безопасности.
Как внедрить DevSecOps без остановки разработки
Внедрение DevSecOps лучше начинать постепенно. Попытка сразу сделать обязательными все проверки просто приведет к росту нагрузки на команды, замедлению релизов и сопротивлению со стороны разработки. Поэтому сначала организации выбирают пилотные проекты, оценивают текущие процессы и добавляют туда базовые механизмы контроля, которые можно встроить в существующий конвейер без лишних изменений.
После внедрения новых подходов важно заранее установить, как сотрудники будут работать с их результатами: какие недочеты нужно исправлять сразу, какие можно оставить в техническом долге, кто отвечает за устранение рисков и кто принимает решения в спорных случаях. По мере развития этой практики компании обучают инженеров, развивают внутреннюю экспертизу и распределяют ответственность между продуктовыми группами.
В итоге безопасность перестает быть финальным барьером перед запуском и становится частью процесса разработки с самого ее начала. Команды находят уязвимости на ранних этапах, быстрее определяют приоритеты и принимают решения по их устранению, а внедрение изменений остается управляемым — с понятным уровнем рисков и без ущерба для скорости релиза.
Источник: Артем Пузанков, руководитель отдела консалтинга безопасной разработки компании «Бастион»
Иллюстрация предоставлена пресс-службой компании
