Внедрение DevSecOps: почему стоимость собственной in-house модели обходится дороже, чем кажется

Практика показывает, что DevSecOps — это не только инструменты. Полная стоимость внедрения безопасной разработки при внутренней модели может в 3–5 раз превышать ожидания. И большая часть скрытых расходов — операционные затраты.

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

Вы узнаете о скрытых расходах на ИБ, дефиците AppSec-инженеров и о том, как правильно рассчитать TCO системы информационной безопасности. Материал будет полезен руководителям ИТ- и ИБ-подразделений, а также специалистам, отвечающим за внедрение безопасной разработки в компаниях.

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

Эта категория включает затраты на персонал, DevSecOps-инструменты и инфраструктуру. Полный стек инструментов — SAST, DAST, SCA, ASOC/ASPM — может варьироваться по стоимости от 14 до 25 млн рублей. При этом важно учитывать конкретный стек разработки компании и в зависимости от этого конфигурировать набор инструментов — определять, что действительно необходимо, а что можно заменить на Open Source.

Вторая, наиболее недооцененная статья расходов — время разработчиков, затрачиваемое не на создание функционала, а на разбор уязвимостей. Это время DevOps-инженера на поддержку пайплайнов, интеграцию ИБ в CI/CD конвейер и исправление парсинга результатов сканирования. Поскольку ни один инструмент не работает без ложных срабатываний сканеров, значительная доля усилий неизбежно уходит на верификацию уязвимостей.

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

Заработные платы квалифицированных AppSec-специалистов и DevSecOps-инженеров на российском рынке являются высокими. Рекрутинг и полное сопровождение найма обходятся еще дороже. Стадия онбординга нового сотрудника может занимать от трех до шести месяцев. Стоимость AppSec-инженера в России с учетом налогов и накладных расходов составляет около 500 000 рублей в месяц на специалиста среднего уровня.

AppSec требует погружения в код, понимания работы приложения, его деплоя, среды выполнения и взаимодействия микросервисов. Дефицит кадров в сфере кибербезопасности делает поиск таких специалистов сложным и дорогостоящим — по оценке специалистов, ситуация на рынке в ближайшие годы вряд ли изменится.

Помимо финансовых аспектов, существуют системные проблемы, которые мешают внедрению безопасной разработки. Рассмотрим их последовательно.

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

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

Конфликт целей разработки и ИБ. Для команды разработки основная ценность — скорость выпуска новых функций и их качество (Time to Market). Для ИБ-подразделения — минимизация рисков. Различие в целевых показателях и KPI этих двух команд создает зону постоянного напряжения и замедляет процессы с обеих сторон.

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

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

Цепной эффект рисков. Перечисленные проблемы не существуют изолированно. Потеря времени разработки на разбор уязвимостей и потеря времени ИБ-команды на онбординг новых сотрудников из-за текучки и дефицита кадров усиливают друг друга. В долгосрочной перспективе это приводит к ситуации, когда инструменты установлены, пайплайны работают, но результаты сканирования не верифицируются и игнорируются. Формируется «безопасная разработка на бумаге» — формальное наличие процессов без реального повышения уровня безопасности.

Для наглядности рассмотрим четыре сценария внедрения безопасной разработки. Исходные условия: команда разработки из 50–100 человек. Требуется оперативно внедрить безопасную разработку, например, в связи с требованиями регулятора.

Первый сценарий — минимальные ресурсы без привлечения внешних специалистов.

Что сделано: два специалиста из внутренней команды выделяют суммарно 5 рабочих дней в месяц на безопасность. Один из разработчиков становится Security Champion, а DevOps-инженер получает дополнительную функцию по безопасности. Профильных компетенций нет — специалисты обучаются в процессе работы. Приобретен Enterprise SAST — статический анализатор с поддержкой вендора.

Расчет на год

• Зарплата каждого специалиста — 300 000 рублей; с налогами и накладными — около 500 000 рублей в месяц
• Стоимость человеко-дня — примерно 22 730 рублей
• Трудозатраты специалистов (120 человеко-дней в год) — около 3 млн рублей
• DevSecOps инструмент Enterprise SAST — 3 млн рублей

Итого: 6 млн рублей в год.

Минусы: специалисты совмещают основную работу с безопасностью, не обладая глубиной знаний. Весь процесс держится на двух конкретных сотрудниках — при их уходе процесс разрушается. Enterprise-инструменты также дают ложные срабатывания и могут не обнаруживать уязвимости. Скрытые расходы на in-house разработку здесь проявляются в полной мере.

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

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

Что сделано: в штат наняты три сотрудника:

• Senior AppSec — 300 000 руб/мес
• Middle AppSec — 150 000 руб/мес
• Senior DevSecOps — 300 000 руб/мес

А также приобретены инструменты SAST, DAST, SCA, а также ASOC/ASPM-система для агрегации и приоритизации уязвимостей.

Расчет на год

• Стоимость DevSecOps in house в месяц — 1 250 000 рублей; в год — 15 млн рублей
• Инструменты (по текущему рынку) — 11 млн рублей

Итого: 26 млн рублей в год.

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

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

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

Третий сценарий — ставка на большую внутреннюю команду и Open Source-инструменты.

Что сделано: в штат наняты 7 человек: два Senior, два Middle, один Junior AppSec, Senior DevSecOps, Middle DevSecOps.

Используется полностью стек Open Source:

• SAST: Semgrep, CodeQL, SonarQube
• Поиск секретов: Gitleaks, TruffleHog
• Проверка конфигураций: Trivy, Grype
• DAST: связка из Katana, HTTPX, Nuclei
• Платформа агрегации: DefectDojo

Расчет на год

• Команда в месяц — около 2,3 млн рублей; в год — 21–22 млн рублей

Итого: около 22 млн рублей в год.

Плюсы: независимость от вендоров, возможность осуществлять AppSec-аналитику силами собственной команды. Вся работа по интеграции, настройке правил, обновлению инструментов и верификации результатов ложится на внутреннюю команду.

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

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

Четвертый сценарий — передача функций безопасной разработки внешнему провайдеру.

Что сделано: найм собственной команды не требуется — используется экспертиза провайдера, например, платформу безопасности приложений Apsafe от Центра кибербезопасности УЦСБ. Внутри компании достаточно 1–2 сотрудников для поддержки услуги — роль связующего звена и контроля устранения уязвимостей. Внедрение занимает недели, а не месяцы. Запуск сканирований, верификация уязвимостей, приоритизация остаются на стороне провайдера.

Расчет на год

• Стоимость услуги — до 5–7 млн рублей. Цена становится предсказуемой и фиксированной. Модель подписки позволяет планировать бюджет на год вперед.

Плюсы: предсказуемый бюджет, что упрощается расчет TCO информационной безопасности, ускорение Time to Market, фокус команды на продукте. Разработчики получают четкие задачи с описанием способов устранения и примерами кода. Аутсорсинг безопасности приложений через сервисную модель — это российское решение для безопасной разработки. Провайдер самостоятельно управляет своей инфраструктурой и штатом, поэтому Заказчику не нужно вникать в подбор специалистов, настройку инструментов или методики их работы.

Минусы: сервисная модель не забирает на себя всю ответственность — внутренние регламенты, SLA и контроль исправлений компания выстраивает сама. Провайдер не формирует культуру безопасности среди разработчиков. Модель не подходит при требованиях изоляции данных или запретах на передачу кода. 

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

Сведем рассмотренные сценарии в сравнительную таблицу по ключевым параметрам.

Анализ показал, что сравнение исключительно стоимости лицензий недостаточно. Необходимо учитывать скрытые расходы ИБ, временные затраты команды и TCO системы информационной безопасности.

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

Сервисная модель предпочтительна в следующих ситуациях:

• отсутствие собственной команды AppSec-инженеров и отсутствие планов по ее созданию;
• наличие жестких требований и сжатых сроков со стороны регуляторов;
• высокая загрузка существующих разработчиков и DevOps-инженеров, не позволяющая отвлекать их на задачи безопасности.

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

Внутренняя модель с Enterprise-инструментами оправдана, когда компания намерена выстраивать собственную экспертизу, безопасность является конкурентным преимуществом продукта, а бюджет позволяет нести значительные расходы. По представленным расчетам — около 26 млн рублей в год для команды из 50–100 разработчиков. 

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

Модель на Open Source подходит организациям, готовым полностью положиться на свою команду. Ключевые условия: наличие специалистов, способных обеспечить высокое качество безопасной разработки; отсутствие зависимости от вендоров и их ценовой политики; готовность компании инвестировать в развитие компетенций команды. Недостаток — работа с Open Source требует значительных усилий, и подходят для этого не все специалисты.

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

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