Эксперты «Новой элиты кибербеза» о том, почему профессия DevSecOps стала востребованной

В рамках проекта «Новая элита кибербеза» SecPost обсудил развитие профессии с Евгением Балком, руководителем департамента развития и архитектуры «Кросстеха», Ксенией Калемберг, управляющим партнером и совладельцем ITD Group, и Владимиром Садовским, исполняющим обязанности руководителя департамента информационной безопасности (CISO) «М.Видео-Эльдорадо».

Народное голосование проекта «Новая элита кибербеза» продолжается. Отдать свой голос за номинантов можно на странице голосования.

Как безопасность стала частью разработки

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

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

Десять лет назад DevSecOps еще оставался экзотикой, доступной преимущественно крупнейшим технологическим компаниям, отмечает Евгений Балк. В России существовали нормативные требования к безопасной разработке, но они не в полной мере учитывали особенности гибких методологий и автоматизированных конвейеров выпуска ПО. За прошедшие годы сформировался рынок специализированных инструментов, а нормативная база стала учитывать современные практики. В частности, в 2024 году был принят обновленный ГОСТ Р 56939-2024, посвященный разработке безопасного программного обеспечения.

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

Зачем понадобился отдельный DevSecOps-инженер

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

«Распределённая ответственность не означает, что всё организуется само», — объясняет Владимир Садовский. Кто-то должен связать требования ИБ с инструментами разработки, настроить проверки, разобраться с ложными срабатываниями, подготовить общие правила и помочь командам ими пользоваться.

В небольшой компании необязательно нанимать отдельного DevSecOps-инженера. Часть его задач может взять на себя разработчик, который дополнительно отвечает за вопросы безопасности в своей команде (security champion). Другой вариант — привлечение внешних специалистов. Но по мере увеличения числа проектов объем работы растет, и заниматься ею по совместительству становится все труднее.

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

Чем занимается DevSecOps-инженер сегодня

Первоначально от DevSecOps-инженера требовалось прежде всего внедрить инструменты проверки безопасности в процесс разработки. Теперь круг его задач существенно расширился.

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

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

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

Где проходит граница между DevSecOps, AppSec и DevOps

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

В общих чертах распределение такое: разработчик отвечает за функциональность приложения, качество своего кода и исправление ошибок. AppSec занимается безопасностью приложения: помогает выявлять угрозы, исследует сложные уязвимости и определяет требования к защите. DevOps обеспечивает работу инфраструктуры, автоматизацию сборки, тестирования и доставки ПО. DevSecOps встраивает проверки безопасности в эти процессы и поддерживает их работу.

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

Например, AppSec помогает определить, при каких условиях обнаруженная уязвимость должна препятствовать выпуску приложения. DevSecOps настраивает соответствующую проверку в автоматизированном конвейере, а разработчик исправляет ошибку. Если требуется временно отступить от установленных правил или принять риск, такое решение согласовывают с уполномоченными руководителями — сам инженер не должен принимать его только ради успешного завершения сборки.

Откуда приходят в профессию и чему придется учиться

В DevSecOps приходят из разработки, DevOps, эксплуатации и информационной безопасности. У каждого направления свои преимущества, но и свои пробелы, которые придется восполнять.

Разработчику легче разобраться в причинах уязвимости и способах ее исправления, но придется освоить инфраструктуру и методы анализа угроз. У DevOps-инженера уже есть опыт автоматизации сборки и выпуска ПО, зато обычно требуется углубить знания по безопасности приложений. Специалисту ИБ знакомы угрозы и принципы защиты, однако ему могут недоставать навыков программирования и понимания повседневной работы команды разработки.

Начинающему DevSecOps-инженеру необходимо уметь читать код, работать с Git и системами непрерывной интеграции и доставки ПО (CI/CD), разбираться в контейнерах, зависимостях и управлении доступом. Понадобится и знакомство с основными методами проверки безопасности: статическим анализом кода (SAST), динамическим анализом приложений (DAST), анализом сторонних компонентов (SCA).

Но технических знаний недостаточно. Нужно уметь оценивать обнаруженные уязвимости с учетом устройства конкретной системы, определять очередность их исправления и объяснять разработчикам, что именно требуется изменить. Если устранение проблемы влияет на сроки проекта или требует значительных ресурсов, придется аргументировать необходимость этих работ перед руководством.

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

Что изменят искусственный интеллект и автоматизация

Уже сейчас инструменты безопасности способны не только обнаруживать уязвимости, но и помогать с их разбором, отсекать ложные срабатывания, объяснять проблемные участки кода и предлагать варианты исправлений.

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

Параллельно возникает новая область ответственности. Разработчики все чаще используют ИИ для написания кода, а некоторые помощники способны самостоятельно изменять репозитории и выполнять команды. Потребуется контролировать не только результат их работы, но и предоставленные им полномочия, доступ к данным и возможности изменения среды разработки.

Ксения Калемберг предполагает, что с распространением ИИ DevSecOps может стать еще ближе к классической информационной безопасности: в задачи инженера войдет организация безопасного использования ИИ-моделей и агентных технологий.

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

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