Минули времена, когда внедрение ИБ-процессов в разработку воспринималось исключительно как способ испортить жизнь и карму девелоперам. Теперь все понимают: инструменты безопасной разработки (БР) необходимы для улучшения TTM и, по сути, являются еще одним видом автоматизированного тестирования ПО. У бизнеса вопросов тоже не возникает, но ровно до тех пор, пока команда справляется своими силами и не просит денег. А длится это, как правило, недолго… После попыток самостоятельного внедрения и поддержки Open Source появляется потребность в более эффективных инструментах (а значит, и в деньгах). При этом внедрение всех процессов, как правило, производится крайне ограниченным штатом сотрудников: наем —задача в принципе непростая, а в AppSec — вообще квест с постоянной неизвестной («Где же его взять?!»).
Наблюдая, как бизнес говорит, что это «дорого, сложно и давайте когда-нибудь никогда потом», мы решили показать, почему лучше все-таки начать сейчас ;) Да, поначалу будет сложно, но цифры (которые никогда не врут) говорят, что это вполне себе способ улучшения процессов, причем с понятным коэффициентом окупаемости.
Экономика безопасной разработки
В расчетах мы будем оперировать понятием ROSI (Return on Security Investment). Метрика показывает: если не заплатить за безопасность сейчас, в дальнейшем есть высокий риск заплатить еще больше. Утечки чувствительных данных, проникновение злоумышленников в корпоративную сеть и другие недопустимые события могут больно ударить по финансам и репутации любой компании.
Важно понимать, что отказ от внедрения безопасной разработки не спасет от затрат на устранение уязвимостей. Заниматься этим все равно придется, только позже: например, во время приемо-сдаточных испытаний или уже во время эксплуатации. Чем это грозит?
На каждом последующем этапе развития продукта мы задействуем все больше людей → устранение уязвимостей обходится все дороже → чем раньше дефект обнаружен и исправлен, тем ниже его стоимость
Если вы не забыли про ИБ и скорректировали недостатки архитектуры еще на этапе планирования, они не будут стоить примерно ничего. А вот «внезапное» появление проблем на более поздних этапах может привести к самым непредсказуемым последствиям — вплоть до обнуления проекта. Существует масса исследований (раз, два), которые показывают разлет стоимости устранения уязвимостей на разных этапах жизненного цикла приложений. Немного занимательной статистики:
| Этап жизненного цикла ПО | Время, ч | Нет Shift-Left* | Есть Shift-Left* |
| Разработка | 4 | - | 16% |
| Тестирование | 8 | - | 64% |
| Пользовательское бета-тестирование / STAGE | 16 | 20% | 16% |
| Релиз / Эксплуатация | 32 | 80% | 4% |
Изменение стоимости устранения дефектов (в % от общего бюджета разработки) за счет выявления уязвимостей на более ранних тапах* * Без учета изменения количества дефектов при внедрении БР. | 10% | 3% |
Устранение отдельных уязвимостей во время эксплуатации может обойтись даже в 100 раз дороже, чем в процессе разработки (например, если придется отозвать партию представительских авто из-за ошибок в ПО). Но чтобы быть ближе к реальности, лучше взять усредненные значения и воспользоваться простым и понятным подходом — кратным увеличением коэффициентов. Если же этот метод вам не близок, используйте методику NIST — она дает немного другие, но вполне жизнеспособные коэффициенты.
Сколько времени уходит на доработку уязвимостей
Итак, мы выяснили, что небезопасная разработка — это дорого. А насколько? Как понять, сколько времени разработчики тратят на устранение пропущенных уязвимостей?
Способ 1. Соберите задачи, которые легли техдолгом либо были отработаны, и посчитайте временные затраты.
Способ 2. Обратитесь к готовым исследованиям. Например, Cisco AppDynamics посчитали, что в среднем команды тратят на исправление дефектов на поздних этапах разработки 57% рабочего времени.
Способ 3. Протестируйте код и рассчитайте плотность рисков (Risk Density). Это наилучший способ.
Risk Density ранжирует проблемы безопасности для количественной оценки рисков и показывает число неисправленных уязвимостей на 1000 строк кода
Если у вас нет возможности самостоятельно рассчитать Risk Density, воспользуйтесь рыночной статистикой:
- Для Open Source — 0,45 ошибки на 1000 строк кода.
- Для проектов, где используется проприетарное ПО и Open Source, — одна ошибка на 1000 строк кода.
Из личной практики аудита
Команды разработки, которые своими силами внедряли и продолжительное время использовали инструменты БР, демонстрировали более высокие результаты по итогам ПСИ и в части техдолга, чем другие команды из тех же компаний. Даже несмотря на все потенциальные минусы DIY-подхода: недостаточную кастомизацию инструментов, частые false positive и т. д.
А что с производительностью?
Отчет Forrester «The Total Economic Impact™ Of GitLab’s Ultimate Plan Cost Savings and Business Benefits» показывает, как растет эффективность девелопмента при автоматизации процессов разработки и тестирования на безопасность:
| Метрика | 1 год | 2 год | 3 год |
| Экономия трудозатрат за счет автоматизации | 0,4 | 0,44 | 0,48 |
| Экономия трудозатрат за счет улучшений мониторинга и устранения неполадок | 0,5 | 0,55 | 0,61 |
| Экономия трудозатрат за счет предотвращения проблем в будущем | 0,3 | 0,33 | 0,36 |
| Экономия трудозатрат в команде разработки | 0,2 | 0,22 | 0,24 |
| Итого: экономия человеческих ресурсов (FTE) | 1,4 | 1,54 | 1,69 |
Также в исследовании показано изменение стоимости устранения ошибок на разных этапах жизненного цикла продукта. Средние целевые показатели индустрии по плотности рисков вполне можно донастроить под конкретную ситуацию (хотя сильно уходить от целевых — неразумно).
| Метрика | 1 год | 2 год | 3 год |
Целевая плотность риска, количество уязвимостей на 1000 строк кода* * 85% — целевая индустриальная оценка Forrester. | 0,33–0,25 | 0,15–0,09 | 0,09–0,03 |
| Дефекты, выявляемые на этапе разработки | 15% | 50% | 85%* |
Сколько стоит безопасность
Итак, мы собрали достаточно данных — пора переходить к практике. Нам понадобится:
- Запросить КП по внедрению.
- Скрупулезно рассчитать, сколько денег потребуется на внедрение безопасной разработки.
- Узнать, сколько стоит время наших разработчиков (учитываем всех, кто участвует в разработке и выкатке приложения).
А дальше — простая арифметика и никакой высшей математики:
- Считаем затраты на проект.
- Рассчитываем стоимость рабочего часа разработчиков.
- Считаем (с помощью рыночной статистики либо внутренних расчетов), сколько времени тратится на устранение дефектов сейчас.
- Перераспределяем дефекты по годам согласно выбранной целевой плотности (либо используем метрику плотности дефектов).
- Рассчитываем, как изменится стоимость трудозатрат с учетом перераспределения дефектов. Считаем, сколько будет стоить устранение дефектов после их перераспределения.
- Рассчитываем эффективность от внедрения процесса автоматизации (статистика, фотография рабочего дня (условный timesheet — чтобы понять, чем занимается сотрудник), учебник экономики).
- Считаем затраты на внедрение (стоимость проекта + стоимость ЧЧ разработки на устранение дефектов из п. 5).
- При необходимости добавляем сугубо экономические показатели: годовая ставка дисконтирования, период дисконтирования, фактор дисконтирования, NPV.
- Считаем RoSI. Складываем все полученные плюшки: разница стоимости устранения уязвимостей (тот самый TTM), экономия от внедрения автоматизации, уменьшение плотности дефектов (оно же «Дефекты, выявляемые на этапе разработки»), экономические показатели и т. д. Отнимаем от полученной суммы затраты на внедрение (п. 8) и делим полученный результат (разность) на затраты на внедрение (п. 8).
Пример расчета
| NPV проекта | 1 год | 2 год | 3 год |
| Экономическая выгода на time to market | 227 413 828 руб. | 207 776 606 руб. | 225 632 925 руб. |
| Затраты на внедрение процесса разработки защищенного ПО | −46 468 000 руб. | -66 947 000 руб. | -61 164 050 руб. |
| Денежный поток | 180 945 828 руб. | 140 829 606 руб. | 164 468 875 руб. |
| Годовая ставка дисконтирования | 20% | 20% | 20% |
| Период дисконтирования | 0,50 | 1,50 | 2,50 |
| Фактор дисконтирования | 0,91 | 0,76 | 0,63 |
| NPV (3 года) | 165 180 186 руб. | 107 132 711 руб. | 104 263 094 руб. |
| ROSI (Return on Security Investment , 3 года) | 68% | 43% | 156% |
***
Хочу еще раз подчеркнуть, что внедрение безопасной разработки — это в первую очередь окупаемость в настоящем, а уже потом — инвестиция в светлое будущее. Это важная задача, которая требует последовательного подхода и постоянного обучения лучшим практикам (to do: не забыть внести обучение в затраты на внедрение БР).
