Сколько стоит внедрение DevSecOps: из чего складывается бюджет

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

Почему нельзя назвать «среднюю цену»

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

Из чего складывается бюджет DevSecOps

1. Лицензии на инструменты

Это самая заметная, но не всегда самая большая статья. Набор инструментов зависит от зрелости процессов (подробнее — в статье «DevSecOps: с чего начать»). Типичные классы:

• SAST — анализ собственного кода;
• SCA — контроль open-source зависимостей и SBOM (что такое SBOM);
• DAST — динамическое сканирование веб-приложений и API;
• управление секретами — например, HashiCorp Vault (подробнее);
• репозиторий артефактов — единая точка контроля сборок.

Различия между классами инструментов разобраны в статье «SAST, DAST, SCA и MAST». Начинать обязательно со всех классов сразу не нужно — это напрямую снижает первоначальный бюджет.

2. Внедрение и интеграция

Покупка лицензии — только начало. Нужно развернуть сервер или подключить облачный сервис, настроить интеграцию с системой контроля версий и CI/CD, задать правила и пороги блокировки сборок, подключить трекер задач и систему отчётности. Время зависит от числа пайплайнов, разнообразия языков и технологий, а также от требований к инфраструктуре: on-premise или облако (см. сравнение моделей размещения).

3. Люди

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

• время AppSec-специалиста или роли «AppSec-инженер» на разбор находок, настройку правил и работу с ложными срабатываниями;
• время DevOps-инженеров на поддержку интеграций;
• время разработчиков на исправление уязвимостей — это реальная нагрузка на бэклог, и её нужно согласовать с продуктовыми командами;
• «Security Champions» — разработчиков в командах, которые частично берут на себя вопросы безопасности.

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

4. Обучение

Разработчики должны понимать, что означает находка сканера и как её исправить, а руководители — как читать отчёты. Обучение включает курсы по безопасной разработке, работу с конкретными инструментами и внутренние регламенты. Бюджет зависит от числа обучаемых и формата (очный, онлайн, практикумы на примерах вашего кода). У AST Cyber Lab есть направление обучения.

5. Поддержка и развитие

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

Модели лицензирования

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

• По числу разработчиков (пользователей). Предсказуемо для небольших команд; стоимость растёт вместе с командой, но не зависит от размера кода.
• По объёму кода или числу приложений. Удобно, когда разработчиков много, а проектов мало; при росте кодовой базы стоимость растёт.
• По числу сканируемых целей (для DAST — сайтов, приложений, API). Подходит для периметра.
• Подписка и бессрочная лицензия с поддержкой. Подписка снижает первоначальные затраты, бессрочная модель предполагает отдельную плату за обновления и поддержку.
• Облако или собственная установка. В облаке меньше затрат на инфраструктуру, при установке у себя — серверы и администрирование на вашей стороне.

Какую модель выбрать — зависит от структуры вашей разработки. Условия лицензирования конкретных продуктов (DerScanner, Sonatype) уточняются по запросу.

Как оценить бюджет: пошаговый подход

1. Инвентаризация. Сколько у вас разработчиков, приложений, репозиториев, пайплайнов; какие языки и фреймворки; что работает во внешнем контуре.
2. Приоритет рисков. Определите, какие системы критичны (платежи, личные кабинеты, внутренние ИС с персональными данными) — с них и начинайте.
3. Минимальный набор. Для большинства команд это SCA и SAST на самых важных проектах; DAST и остальное добавляется следующими этапами.
4. Трудозатраты. Оцените в человеко-часах: внедрение, регулярный разбор находок, исправление, обучение. Умножьте на ставку ваших специалистов или подрядчика.
5. Запрос предложений. Запросите оценку у нескольких вендоров или интегратора, указав одни и те же исходные данные, и сопоставьте по единой модели.
6. Пилот. Перед крупной покупкой проведите ограниченный пилот — как это организовать, описано в материале об open-source и коммерческих инструментах и в плане пилота SAST/SCA.

Где можно сэкономить, а где нельзя

• Можно: начинать с ограниченного охвата, использовать open-source для отдельных задач (с учётом затрат на их поддержку), выстраивать процесс поэтапно, обучать внутренних champions вместо постоянного привлечения внешних специалистов.
• Нельзя: закладывать нулевой бюджет на разбор находок и исправление; покупать инструмент без владельца процесса; сравнивать предложения только по цене лицензии без учёта внедрения и поддержки.

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

Как мы работаем над оценкой

AST Cyber Lab занимается внедрением DevSecOps в Казахстане и странах Центральной Азии. Мы начинаем с карты DevSecOps: фиксируем текущую зрелость, список систем и желаемый результат — после этого оценка бюджета строится на ваших данных, а не на усреднённых цифрах.

Пример: как две компании получают разный бюджет

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

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

Скрытые расходы, о которых стоит спросить заранее

• Стоимость роста. Как изменится цена, если число разработчиков или приложений вырастет вдвое, и есть ли в договоре зафиксированные условия продления.
• Дополнительные модули. Входят ли в базовую лицензию отчётность, интеграции с трекерами и IDE, API, поддержка нужных языков.
• Инфраструктура. Серверы, базы данных, резервное копирование и мониторинг при установке в собственном контуре.
• Условия поддержки. Часы работы, языки общения, сроки реакции и наличие специалистов в вашей стране.

Запишите эти вопросы в единый шаблон запроса предложений, чтобы все поставщики отвечали на одно и то же.

Частые вопросы

Источники

• GitLab Docs: Static Application Security Testing (SAST) — различия функций по тарифам
• Sonatype: Nexus Repository — варианты развёртывания
• IBM: Cost of a Data Breach Report