Как обосновать бюджет на AppSec перед руководством

Руководство одобряет бюджет на безопасность приложений, когда видит не список инструментов, а снижение конкретных рисков в деньгах, регуляторные обязательства и понятные метрики результата. Строгий «ROI» в AppSec посчитать сложно, потому что эффект — это предотвращённые события; поэтому обоснование строят на сценариях потерь, стоимости исправления на разных этапах и измеримом прогрессе.

Почему «ROI» в безопасности считается иначе

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

Шаг 1. Опишите риски языком бизнеса

Вместо «у нас N критических уязвимостей» покажите, какие бизнес-процессы они затрагивают:

• какие системы обрабатывают платежи, персональные данные клиентов, коммерческую тайну;
• что случится при взломе или простое: остановка сервиса, штрафы, претензии клиентов и партнёров, репутационный ущерб;
• какие внешние требования уже действуют: регулятор, стандарты (например, PCI DSS — см. требования к скриптам платёжных страниц), договорные обязательства перед партнёрами.

Начните с 3–5 наиболее критичных систем. Руководству проще принять решение по конкретным активам, чем по «безопасности в целом».

Шаг 2. Опирайтесь на проверяемые внешние данные

Самый известный открытый источник по стоимости инцидентов — ежегодный отчёт IBM и Ponemon Institute Cost of a Data Breach. На странице отчёта за 2026 год IBM указывает среднемировую стоимость утечки данных в 4,99 млн долларов США (рекордный показатель, рост на 12% к предыдущему году) и отмечает, что организации, активно использующие ИИ и автоматизацию в безопасности, экономят 1,93 млн долларов по сравнению с теми, кто их не применяет.

Важные оговорки, которые стоит озвучить сами, чтобы не потерять доверие аудитории:

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

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

Шаг 3. Покажите разницу в стоимости исправления

Аргумент «чем раньше найдена уязвимость, тем дешевле её устранить» понятен руководству и подтверждается практикой. Но не приводите «красивые» коэффициенты вроде «в 100 раз дешевле» без источника — их происхождение часто не проверяется. Надёжнее посчитать на собственных данных:

• возьмите 5–10 недавних уязвимостей, найденных на пентесте или в проде;
• оцените трудозатраты на исправление: анализ, правка, повторное тестирование, внеплановый релиз, коммуникации;
• сравните с трудозатратами на исправление аналогичной уязвимости на этапе pull request — такие данные вы получите в пилоте SAST/SCA.

Шаг 4. Сформулируйте формулу эффекта

Для презентации достаточно простой и прозрачной модели. Используйте ожидаемые годовые потери (ALE):

• ALE до = вероятность инцидента в год × размер потерь;
• ALE после = та же вероятность с учётом мер × потери;
• Эффект = ALE до − ALE после − годовая стоимость программы AppSec.

Все параметры — оценочные, поэтому показывайте диапазоны (оптимистичный, базовый, консервативный сценарии) и явно называйте допущения. Руководство ценит честную модель с оговорками выше «точной» цифры, которую нельзя защитить.

Вторая часть эффекта — то, что считается проще: сокращение трудозатрат на ручные проверки, ускорение выпуска релизов без «аварийных» откатов, подготовка к аудитам с готовыми отчётами. Структуру затрат для знаменателя формулы разбирает статья «Сколько стоит внедрение DevSecOps».

Шаг 5. Выберите метрики, которые будут показывать прогресс

Метрики нужны и для обоснования, и для отчёта после запуска. Рабочий набор:

• Охват: доля приложений и репозиториев, подключённых к сканированию;
• Время устранения: среднее время исправления критических уязвимостей (MTTR);
• Накопленный долг: число открытых критических и высоких уязвимостей и динамика;
• Доля блокировок: сколько сборок остановлено quality gate и сколько из них исправлено в срок;
• Зависимости: доля компонентов с известными уязвимостями, наличие SBOM (что такое SBOM);
• Выявляемость: доля уязвимостей, найденных до продакшена, против найденных пентестом или в эксплуатации.

Договоритесь с руководством о целевых значениях на 6–12 месяцев — это превращает бюджет в понятное обязательство.

Шаг 6. Предложите поэтапный план и пилот

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

1. Пилот на 1–2 критичных приложениях; цель — получить собственные данные о находках и трудозатратах.
2. Расширение на остальные критичные системы, включение quality gates.
3. Масштабирование на всю разработку, регулярная отчётность.

Решение о следующем этапе принимается по метрикам пилота — для руководства это ограничивает риск неудачной покупки.

Типичные ошибки в обосновании

• Запугивание без цифр. Общие страшные примеры работают один раз; потом нужны ваши системы и ваши риски.
• Технический язык. Руководителю не нужны названия классов уязвимостей, ему нужен эффект для бизнеса.
• Один «большой» бюджет без этапов. Его проще отложить.
• Игнорирование затрат на людей и исправление. Финансовый директор заметит их позже и усомнится в остальных расчётах.
• Неподтверждённые данные. Любую внешнюю цифру сопровождайте названием отчёта, годом и ссылкой.

Как выстроить саму презентацию

Структура выступления перед руководством, которая хорошо работает на практике, укладывается в пять слайдов:

• Ситуация. Какие системы критичны, что известно об их уязвимостях сейчас (по результатам пентестов, аудитов, пилота).
• Риск. Сценарии потерь для 3–5 активов и внешние ориентиры с указанием источника.
• Предложение. Что именно вы собираетесь внедрить и в каком порядке — без перечисления функций инструментов.
• Стоимость. Лицензии, внедрение, люди, обучение, поддержка по годам; разбивка по этапам.
• Результат. Метрики, целевые значения и точки принятия решения: когда вы вернётесь за следующим этапом.

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

Как работать с возражениями

• «У нас никогда не было взломов». Отсутствие обнаруженных инцидентов не означает отсутствия уязвимостей. Предложите пилот или оценку защищённости, чтобы получить факты.
• «Разработчики замедлятся». Покажите режим «только информирование» на старте и измеряйте время пайплайна; блокировки включаются постепенно.
• «Дорого». Перейдите от общей суммы к поэтапному плану и к сравнению с потенциальными потерями по вашим критичным системам.
• «Есть бесплатные инструменты». Они есть, но требуют времени на поддержку; сравнивайте полную стоимость владения, а не цену лицензии.

Что делать после одобрения бюджета

Обоснование не заканчивается решением. Через 3–6 месяцев вернитесь к руководству с отчётом по согласованным метрикам: какой охват достигнут, сколько критичных уязвимостей закрыто, как изменилось время устранения, сколько проблем остановлено до продакшена. Если цифры не дотягивают до плана, честно объясните причину и предложите корректировку. Такая прозрачность формирует доверие и упрощает согласование следующего этапа программы.

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

Источники

• IBM: Cost of a Data Breach Report
• PCI SSC Blog: требования PCI DSS для e-commerce, вступающие в силу 31 марта 2025