ИБ-директор рассказывает о покрытии анализом кода и о количестве найденных уязвимостей, а финансового директора интересует только возврат инвестиций. Знакомое расхождение? Рассказываем и показываем, как наладить коммуникацию и показать правлению реальную ценность DevSecOps.
- 1. Введение
- 2. Парадокс: обе стороны правы одновременно
- 3. Пять причин, почему ИБ-метрики не убеждают бизнес
- 4. Восемь измерений ценности: фильтр для любой метрики
- 5. Модель: три уровня, связанных причинно-следственной логикой
- 6. Ловушка Гудхарта: как не сломать метрики, превратив их в KPI
- 7. Каскад: как одна уязвимость превращается в деньги
- 8. Дашборд для топов (executive dashboard): один экран, три аудитории
- 9. Кейс: возврат инвестиций 242 % в финансовой организации
- 10. Выводы
Введение
Спросите свою ИБ-команду, зачем компания делает DevSecOps. Вам ответят про тестирование и анализ (SAST, DAST, SCA), покрытие репозиториев и время восстановления (MTTR). А потом спросите людей со стороны бизнеса — ответы будут варьироваться от «не знаю» до «так требует регулятор».
Проблема не в инструментах, а в отсутствии понятной коммуникации. ИБ-команда предъявляет бизнесу метрики, которые не способны его убедить, — и делает это годами, искренне не понимая, почему её не слышат.
Мы подошли к проблеме основательно и в этой статье представим конкретные меры, которые помогут преодолеть разрыв: три уровня метрик, связанных причинно-следственной логикой, один дашборд на три аудитории и расчёт возврата инвестиций, который выдерживает вопросы финансового директора. Плюс план внедрения на 90 дней и семь способов всё испортить.
Парадокс: обе стороны правы одновременно
Картина, которую я вижу у клиентов регулярно. ИБ-директор (CISO) приходит на бюджетный комитет с честным отчётом: покрытие статическим и динамическим анализом выросло с 70 до 95 процентов, среднее время реакции снизилось, критических инцидентов за квартал — ноль. Всё, что он показывает, — правда. Финансовый директор (CFO) дослушивает и задаёт единственный вопрос: «А что я получил за эти 50 миллионов?». CISO снова не понимает, почему достижения его команды обесценивают.
Вот несколько цифр, которые ярко демонстрируют «провал» в коммуникации ИБ и бизнеса.
Рисунок 1. Статистика, указывающая на недостатки коммуникации
Ключевой вывод: не работает перевод — из операционного языка ИБ в язык прибылей и убытков. И именно над этим необходимо работать.
Пять причин, почему ИБ-метрики не убеждают бизнес
Мы выделили пять основных причин неудачной коммуникации. Это не проблема конкретного CISO — это проблема архитектуры принятых метрик DevSecOps.
- Метрики активности вместо метрик результата
Количество запусков сканеров, число найденных уязвимостей, проценты покрытия — это всё про активность команды. Бизнес же покупает результат: меньше инцидентов, быстрее релизы, ниже стоимость владения.
Симптом: в отчёте написано «запускаем SAST еженедельно».
- Метрики тщеславия: «нашли больше — значит лучше»
Я видел десятки дашбордов, где рост числа найденных дефектов подаётся как достижение. Но ведь чаще он означает, что обновились правила сканера или ужесточился профиль проверки. Защищённость продукта при этом не изменилась.
Симптом: «+ 30 % уязвимостей к третьему кварталу — это успех?»
- Нет связи с прибылью и убытком (P&L)
Проведите простой тест. Возьмите любую метрику из вашего квартального отчёта и ответьте на вопрос: как её динамика влияет на выручку, маржу или отток клиентов?
Если внятного ответа нет — эта метрика не про бизнес. Она может быть полезной, нужной, технически корректной. Но на бюджетном комитете она не сработает.
Симптом: «Покрытие 95 %» — и тишина в ответ на вопрос, как это связано с удержанием клиентов.
- Не считается стоимость самих процессов ИБ
Ручной разбор тысяч находок статического анализа — это часы работы инженеров, умноженные на их ставку. Задержка релиза из-за ИБ-гейта без SLA — это упущенная выручка. Ни то ни другое обычно нигде не фигурирует.
В результате совокупная стоимость владения процессом безопасной разработки скрыта: компания видит цену лицензий и не видит цену человеко-часов, которые эти лицензии порождают.
Симптом: стоимость разбора одной находки никто никогда не считал.
- У метрики нет владельца со стороны бизнеса
Если ни один продуктовый руководитель и ни один финансист не несёт ответственности за конкретный показатель, — тот живёт в вакууме и не влияет на решения.
Симптом: в графе «владелец» написано «ИБ-команда». То есть — никто.
Запомните эти пять пунктов. Мы вернёмся к ним в разделе про антипаттерны — там будет готовый чек-лист замен.
Восемь измерений ценности: фильтр для любой метрики
Прежде чем показать новые метрики, надо договориться, что мы вообще измеряем. Вот восемь измерений, в которых бизнес реально оценивает безопасную разработку.
Рисунок 2. Метрики оценки DevSecOps через оптику бизнеса
Правило, которое стоит повесить на стену: каждая новая метрика должна попадать хотя бы в одно из этих восьми измерений. Если не попадает — это метрика для внутреннего отчёта ИБ. Она имеет право на существование, но не имеет права занимать место на слайде для топ-менеджмента.
Модель: три уровня, связанных причинно-следственной логикой
Метрики DevSecOps должны жить на трёх уровнях:
- L1. Операционный — что делает ИБ-команда. Гигиена, проще говоря.
- L2. Инженерный — как безопасность влияет на скорость и качество поставки.
- L3. Бизнес — как всё это превращается в деньги.
Уровни связаны снизу вверх. Без этой связки вы либо тонете в технике и не видите бизнеса, либо рассказываете красивые истории про финансовые коэффициенты, под которыми нет операционной правды. Второе опаснее: такие истории живут ровно до первого внимательного CFO.
Уровень 1-й, операционный: гигиена, а не доказательство ценности
Базовый слой. Без него ничего не поедет — но сам по себе он никого не убеждает.
Рисунок 3. Метрики и ориентиры для операционного уровня
Почему MTTR обязательно считать по категориям
Это тот пункт, который чаще всего пропускают, — а он определяет, окажется ли ваш норматив по соглашению о качестве (SLA) выполнимым. Время устранения инъекции в собственном коде и время устранения уязвимости в транзитивной зависимости — это два разных процесса, и вот почему.
- Разная природа исправления. SQL-инъекция в своём репозитории — это правка, полностью подконтрольная команде: несколько часов от тикета до мерджа. Уязвимость в библиотеке — это ожидание патча от апстрима, проверка обратной совместимости, регрессионное тестирование, иногда миграция мажорной версии. А иногда патча нет вовсе, и остаётся компенсирующая мера: правило на WAF, виртуальный патч, отключение функциональности.
- Разные владельцы. В первом случае владелец — ваша команда разработки. Во втором вы фактически зависите от внешнего сообщества или вендора, и ваш MTTR снизу ограничен скоростью их реакции. Требовать от команды 24 часа на то, что от неё не зависит, — верный способ обесценить метрику в глазах разработчиков.
- Разные рычаги улучшения. Свой код чинится обучением, линтерами и воспитанием лидеров безопасности (security champions). Зависимости — политикой обновлений, ботами обновления зависимостей, приёмкой библиотек и дисциплиной SBOM. Если вы смотрите на один усреднённый MTTR, вы не понимаете, какой из двух рычагов дёргать.
- Усреднение прячет провал. Средние 24 часа могут складываться из двух часов по 90 % находок и тридцати дней по тем самым 10 %, которые как раз и опасны.
Вывод простой: одна цифра MTTR — это метрика, которая не отражает реальность.
Чему на этом уровне НЕ надо радоваться:
«Мы нашли 1000 уязвимостей» → а сколько из них критически важны для бизнеса? Сколько исправлено?
«У нас покрытие 95 %» → а качество правил? А доля ложных срабатываний? А время реакции?
«Мы сканируем еженедельно» → и что от этого изменилось в защищённости продукта?
Уровень 2-й, инженерный: язык, на котором с вами будет говорить технический директор (CTO)
Самый интересный уровень с точки зрения коммуникации. Здесь ИБ впервые начинает говорить с разработкой на общем языке, и именно здесь чаще всего рождается союз CISO и CTO. В основе — четыре классические DORA-метрики, которые давно стали индустриальным стандартом и которые ваши коллеги из разработки уже знают: частота релизов, время от коммита до прода, доля неудачных изменений, время восстановления. К ним ИБ добавляет четыре своих.
Рисунок 4. Метрики и ориентиры для инженерного уровня
Здесь может возникнуть вопрос: зачем это руководителю разработки? Отвечаем:
- Скорость и безопасность оказываются в одной системе координат. Их больше не нужно противопоставлять — они считаются вместе.
- Снимается вечный конфликт «ИБ против разработки». Появляются общие KPI вместо взаимоисключающих
- Это прямой путь к бизнес-эффекту. Именно через эти метрики безопасность влияет на Time-to-Market и совокупную стоимость владения.
Что отслеживать ежедневно: MTTR по критически значимым, Pipeline Block Time, долю автоматического триажа, долю откатов по ИБ-причинам.
Уровень 3-й, бизнес: метрики, ради которых всё затевалось
Уровень, который понимают генеральный и финансовый директора. Каждый показатель здесь связан с прибылями и убытками, оттоком клиентов или капитализацией.
Рисунок 5. Метрики и эффекты для бизнесового уровня
Формула, ради которой строится вся система:
ROI DevSecOps = (экономия + предотвращённые потери − инвестиции) ÷ инвестиции
Именно ради этого выстраиваются три уровня метрик. Всё остальное — подготовка.
Ловушка Гудхарта: как не сломать метрики, превратив их в KPI
Отдельное предупреждение, без которого модель опасна. Закон Гудхарта: как только показатель становится целью, он перестаёт быть хорошим показателем. Для DevSecOps это не абстракция, а вполне конкретные грабли.
Поставьте команде KPI «снизить число открытых уязвимостей» — и вы получите не более защищённый продукт, а более мягкие правила сканера и массовое закрытие тикетов со статусом «принятый риск». Поставьте KPI «нарастить покрытие» — получите сканирование пустых репозиториев.
Противоядие — парные метрики, которые невозможно улучшить обманом одновременно:
- покрытие и доля ложных срабатываний;
- скорость релизов и доля откатов по ИБ-причинам;
- число закрытых находок и доля повторно открытых;
- Time-to-Market и доля сбойных деплоев (Change Failure Rate).
И правило, которое я считаю обязательным: никогда не привязывайте премию к абсолютному числу найденных или закрытых уязвимостей. Это создаёт прямой финансовый стимул не находить их.
Каскад: как одна уязвимость превращается в деньги
Чтобы три уровня перестали быть абстракцией, проследим путь одной уязвимости.
Шаг 1. Обнаружение (L1). Разработчик отправляет пулл-реквест. SAST, DAST и SCA находят уязвимость прямо на этапе кода. Секунды или минуты.
Шаг 2. Триаж (L1). Ложное срабатывание отсеивается автоматически. Истинное получает приоритет по риску для бизнеса, а не «по баллу CVSS». Разница принципиальная: критически значимая по CVSS уязвимость на тестовом стенде и средняя по CVSS в платёжном шлюзе — это разные истории.
Шаг 3. Устранение (L1). Разработчик чинит дефект до мерджа. Контекст ещё у него в голове, код не ушёл в прод — стоимость исправления минимальна.
Шаг 4. Инженерный эффект (L2). Конвейер не блокируется. Lead Time не растёт. Доля откатов по ИБ-причинам снижается.
Шаг 5. Бизнес-эффект (L3). Релизы выходят в срок. Доверие клиентов растёт. Затраты на доработки после прода падают.
Здоровье всего каскада показывают четыре цифры: время обнаружения, время исправления, доля ложных срабатываний, Pipeline Block Time.
Рисунок 6. Цена ошибки по стадиям
Это и есть финансовая основа возврата инвестиций в DevSecOps. Если процесс ловит дефект на этапе кода, а не после релиза, — вы экономите два порядка на каждом баге. Умножьте на количество багов в год.
Главная мысль, которую стоит унести из этого раздела: DevSecOps — это не количество найденных багов. Это сокращение пути от строки кода до прода без потери качества. Если ваш DevSecOps этот путь удлиняет — он не работает, даже когда все метрики ИБ зелёные.
Дашборд для топов (executive dashboard): один экран, три аудитории
Дальше — как показать всё это на одном экране, не превратив его в стену цифр.
Идея — один экран, три блока.
Верхний блок (L3) — для CEO и CFO: Revenue at Risk, Compliance Coverage, ROI, TCO.
Средний блок (L2) — для CTO: DORA-метрики, Pipeline Block Time, Security Debt Ratio, доля откатов по ИБ-причинам.
Нижний блок (L1) — для CISO: MTTD / MTTR, покрытие критически значимых репозиториев, доля автоматического триажа, доля ложных срабатываний.
Каждый смотрит в свой блок — но все видят одну и ту же картину, потому что уровни связаны каскадом и сверху видно, чем питается результат.
Четыре принципа, которые мы вывели на практике:
- Один взгляд — один вывод. Каждая панель отвечает на конкретный вопрос руководителя. Если, глядя на панель, вы не можете одной фразой сказать, что она показывает, — переделайте её.
- Не более семи метрик на роль. Это когнитивный предел. Вы можете месяцами собирать данные, но если у CFO на экране 30 цифр — он не посмотрит ни на одну.
- Тренд важнее значения. Текущая цифра без динамики бессмысленна. Минимум — сравнение с прошлым кварталом и целевое значение.
- Связь с действием. У каждой красной зоны есть ответственный и сценарий восстановления. Не «упало — ищите виноватого», а «упало — известный плейбук».
Отсюда, кстати, главное отличие. Операционный дашборд — про детали и реальное время. Директорский дашборд — про тренды и решения. Попытка совместить их в одном экране убивает оба.
Кейс: возврат инвестиций 242 % в финансовой организации
Чтобы всё вышесказанное не звучало теоретично — расчёт на реальных вводных.
Профиль: финансовая организация, 600 разработчиков, 80+ продуктов в портфеле, 12 месяцев после внедрения трёхуровневой системы метрик.
Инвестиции: 38 млн ₽ в год. Лицензии на SAST, DAST и SCA-инструменты, программа обучения команд разработки, выделенный архитектор безопасности приложений (AppSec).
Рисунок 7. Что измерили через год
Важно: Lead Time сократился не за счёт ослабления контроля, а за счёт раннего выявления и автоматизации триажа. Это принципиально: если бы мы просто убрали гейт, цифра была бы такой же, а смысла в ней — никакого.
Два расчёта вместо одного
Здесь начинается то, что отличает защищаемый расчёт от нарисованного. Показывайте CFO обе цифры сразу — он всё равно спросит.
Консервативный расчёт — только твёрдая экономия:
ROI = (52 − 38) ÷ 38 = 37 %
Даже если полностью выбросить предотвращённые потери как «вероятностные» — проект окупается на одной лишь фактической экономии бюджета доработок. Этот аргумент снимает главное возражение финансиста ещё до того, как он его сформулирует.
Полный расчёт — с учётом предотвращённых потерь:
ROI = (52 + 78 − 38) ÷ 38 = 242 % (× 2,4)
То есть каждый вложенный рубль принёс 2,4 рубля чистого эффекта сверх возврата самого вложения.
Дополнительную выручку от ускорения Time-to-Market (+ 14 млн ₽ в квартал) я сознательно не включаю в формулу — чтобы не смешивать доход и экономию и не получить двойной счёт. Она идёт отдельной строкой.
Срок окупаемости: почему пять месяцев, а не три с половиной
Формально: 130 млн эффекта за год — это около 10,8 млн ₽ в месяц, и 38 млн инвестиций «отбиваются» за 3,5 месяца работы системы в штатном режиме.
Но система не выходит на полную мощность в первый же день. Первые три месяца — это развёртывание, настройка правил, обучение команд: затраты идут, эффекта почти нет. С учётом этой кривой выхода точка безубыточности приходится примерно на пятый месяц с начала проекта. Именно эту цифру честно называть правлению.
Что важно понимать про эти цифры
Они стали возможны не потому, что у компании было больше денег. Они стали возможны потому, что работала трёхуровневая система метрик. Без неё нечего предъявить: экономию на Cost of Quality нельзя посчитать, если у вас нет базовой линии по числу и стоимости постпродовых доработок.
Отсюда практический вывод: прежде чем считать возврат инвестиций, зафиксируйте базу (baseline). Расчёт без точки отсчёта — это не более чем презентация.
Рисунок 8. Этапы и сроки ввода новой системы
Этап 2 — самый недооценённый. Его регулярно пытаются проскочить: «давайте сначала соберём дашборд, а с бизнесом потом договоримся». Не договоритесь. Метрика без владельца со стороны бизнеса не доезжает до правления — она остаётся графиком на стенке.
Что измеряем на выходе:
- Качество данных: покрытие SAST / DAST / SCA, точность автоматического триажа.
- Скорость: Lead Time, MTTR, Pipeline Block Time.
- Бизнес-эффект: ROI, TCO, Time-to-Market, Compliance Coverage.
Критерий успеха предельно простой: цифры одновременно понятны и собственнику, и инженеру. Если CFO кивает, а CTO морщится — что-то не так. Если морщатся оба — вы построили красивую отчётность вместо системы измерения.
Выводы
DevSecOps перестаёт быть эзотерической дисциплиной для узкого круга посвящённых ровно в тот момент, когда вы начинаете говорить о нём в терминах возврата инвестиций, Time-to-Market, стоимости качества и покрытия требований регуляторов.
Когда бизнес видит экономическую эффективность и соответствие всем требованиям, ИТ-директор (CIO) видит повышение скорости выпуска продукта в прод, а CISO понимает связку результата своей работы с результатами бизнеса.
Для создания такой системы не нужно много времени — хватит 90 дней. Поэтому, если вы сейчас защищаете бюджет на безопасную разработку и вам тяжело, — скорее всего, вам не хватает одной системы координат с бизнесом.
