Никто не спорит, что безопасность программного обеспечения при современном уровне цифровизации безусловно важна.
Но сторонники DevSecOps уверяют, что без внедрения этой методологии не обойтись сегодня ни одному разработчику. Так ли это? Или все же редко обновляемым приложениям можно обойтись регулярными тестами? Разбираемся в этой статье.
При этом формулы расчета такой вероятности даже если и существуют, то относятся к категории алхимии. Но есть вполне объективные метрики, по которым можно оценить безопасность приложения. Рассмотрим три наиболее простых:
Вроде бы все выглядит очень понятно и даже не слишком сложно. А выполнение заданного уровня метрик может снизить вероятность взлома приложения до минимума.
Мы занимаемся безопасной разработкой с 2019 года и набрали определенный пул клиентов, которые внедряли за это время соответствующие процессы и методики. Большая часть этих заказчиков – банки и другие финансовые учреждения. И можем поделиться некоторыми выводами и наблюдениями, касающимися снижения качества обработки информации, связанной с ИБ, в процессе разработки. Особенно интересно посмотреть на размер компаний.
Снижение производительности мы считали в среднем увеличении интервалов между выходами двух последовательных релизов в течение года. Переходный период мы не учитывали, поскольку в нем снижение производительности бывает кратным.
Очевидно, что для крупных команд снижение менее существенно – ведь процессы выстроены лучше и работа гораздо лучше декомпозирована. Там, где каждый занимается своим делом, вероятность ошибки резко снижается. А вот почему веб-приложения с личным кабинетом на сайте меньше страдают от внедрения безопасной разработки? Просто потому, что к нему предъявляется меньше требований. Те самые метрики, что мы разбирали выше, имеют более щадящие значения.
Поэтому и получается, что DevSecOps, если он не «для галочки», – вполне безобидная (и не тормозящая процессы) технология с точки зрения бизнеса. Опять же, для серьезных компаний. Но отметим и то, что динамика снижения производительности положительная. Чем дольше работает команда в DevSecOps, тем меньше ошибок.
На другой стороне, как правило, невнятные заявления о «большей безопасности», «снижении рисков» и так далее. Попробуем сформулировать преимущества безопасной разработки более четко. Ведь когда-то плюсы даже более простого процесса DevOps также были неочевидны и измерялись скоростью донесения продукта до пользователя. И цифры отличались в десятки раз у разных команд и продуктов.
Вот явные преимущества внедрения процесса безопасной разработки:
В РФ есть ФСТЭК и ЦБ, которые выпускают различные (не всегда согласованные, но все же неплохие) требования к безопасной разработке. Это и ГОСТ 56939 с последними проектами изменений, и ГОСТ 15408 с небезызвестным ОУД4, и даже приказы о сертификации.
Однако, вводимые через «не хочу» требования приводят к печальным результатам: безопасная разработка есть, но только на бумаге. При этом в организациях, где DevSecOps уже существовал, даже такие жесткие требования, как профиль защиты от Банка России выполняются относительно безболезненно.
То есть те, кто задумывался о безопасности, требования выполняют. А те, кому важно лишь выполнять требования, не получают безопасности. Причем зачастую создать формальную видимость соответствия, но не трогать разработчиков, стоит дороже, чем реально привести процессы в порядок.
Вот такой парадокс, в условиях которого крайне рекомендуем начинать всегда не с комплаенса, а с повышения реальной безопасности процесса разработки. Тогда и «бумажные» требования автоматически подтянутся.
Если же ваш продукт не требует безопасности (это может быть простой графический редактор), то буквы Sec можно убрать и ограничиться DevOps. Как и в случае, если вас не слишком беспокоит защита данных ваших клиентов.
В заключение отметим, что проекты, в которых участвуют три разработчика, явно не имеют бюджета на безопасность. По нашим наблюдениям, окупается DevSecOps в командах от 10 человек, именно на таком объеме он выгоден экономически.
Но сторонники DevSecOps уверяют, что без внедрения этой методологии не обойтись сегодня ни одному разработчику. Так ли это? Или все же редко обновляемым приложениям можно обойтись регулярными тестами? Разбираемся в этой статье.
Метрики безопасной разработки
Как многие уже знают, безопасная разработка – это процесс. Он включает в себя проверки, дополнительные тесты, аналитическую работу и так далее. Конечная цель всех этих действий – снижение вероятности того, что в ПО появится уязвимость.При этом формулы расчета такой вероятности даже если и существуют, то относятся к категории алхимии. Но есть вполне объективные метрики, по которым можно оценить безопасность приложения. Рассмотрим три наиболее простых:
- число срабатываний статического анализатора с заданным уровнем (например, не более одного высокой критичности и не более 20 – средней);
- число срабатываний динамического анализатора с заданными уровнем (например, ни одного высокой критичности и не более трёх – средней);
- полнота покрытия функций безопасности автоматическими тестами (например, не менее 95%).
Вроде бы все выглядит очень понятно и даже не слишком сложно. А выполнение заданного уровня метрик может снизить вероятность взлома приложения до минимума.
Снижение производительности: DevSecOps медленнее DevOps
И тут появляется первое «НО». Даже просто на расчет метрик требуются ресурсы. Начиная от специалистов по DevOps и DevSecOps, заканчивая расходами на анализаторы (которые чаще всего не бесплатны), а также непосредственно разработчиками – им помимо бизнес-логики необходимо уделять внимание и «чистоте» кода.Мы занимаемся безопасной разработкой с 2019 года и набрали определенный пул клиентов, которые внедряли за это время соответствующие процессы и методики. Большая часть этих заказчиков – банки и другие финансовые учреждения. И можем поделиться некоторыми выводами и наблюдениями, касающимися снижения качества обработки информации, связанной с ИБ, в процессе разработки. Особенно интересно посмотреть на размер компаний.
Снижение производительности мы считали в среднем увеличении интервалов между выходами двух последовательных релизов в течение года. Переходный период мы не учитывали, поскольку в нем снижение производительности бывает кратным.
| Тип приложения | Численность команды (чел.) | Снижение производительности |
| Мобильный банкинг | До 10 | 40% |
| 10-20 | 30% | |
| 20-40 | 20% | |
| Веб-приложение и личный кабинет | До 10 | 25% |
| 10-20 | 15% | |
| 20-40 | 10% |
Очевидно, что для крупных команд снижение менее существенно – ведь процессы выстроены лучше и работа гораздо лучше декомпозирована. Там, где каждый занимается своим делом, вероятность ошибки резко снижается. А вот почему веб-приложения с личным кабинетом на сайте меньше страдают от внедрения безопасной разработки? Просто потому, что к нему предъявляется меньше требований. Те самые метрики, что мы разбирали выше, имеют более щадящие значения.
Поэтому и получается, что DevSecOps, если он не «для галочки», – вполне безобидная (и не тормозящая процессы) технология с точки зрения бизнеса. Опять же, для серьезных компаний. Но отметим и то, что динамика снижения производительности положительная. Чем дольше работает команда в DevSecOps, тем меньше ошибок.
Как быстро оценить плюсы DevSecOps
Описанное выше снижение производительности команды разработки и стоимость внедрения процессов безопасности обычно называют среди основных минусов DevSecOps.На другой стороне, как правило, невнятные заявления о «большей безопасности», «снижении рисков» и так далее. Попробуем сформулировать преимущества безопасной разработки более четко. Ведь когда-то плюсы даже более простого процесса DevOps также были неочевидны и измерялись скоростью донесения продукта до пользователя. И цифры отличались в десятки раз у разных команд и продуктов.
Вот явные преимущества внедрения процесса безопасной разработки:
- Периодичность внешних пентестов можно снизить с одного на релиз до, скажем, одного в год. Стоимость тестирования на проникновение сильно варьируется, в зависимости от приложения, но даже с учетом разброса от 300 тыс рублей до 3 млн рублей экономия вполне ощутима. Если у вас небольшое приложение, которое ведет команда из 3 человек, то и пентест будет, вероятно, по нижней границе вилки. А вот анализ приложения, над которым работают 20 человек, уже оценивается в несколько миллионов. Таким образом, стоимость пентеста сопоставима примерно с месячным ФОТ разработчиков.
- Автоматизация конвейера безопасности, как и в случае с переходом от классической разработки к DevOps. Говоря простыми словами, то, что раньше проверяли и собирали руками, теперь делает конвейер. Нивелируется зависимость от разработчика, который «знает эту программу с альфа-версии». Да, при этом появляется необходимость в постоянном контроле и отлаживании процессов DevSecOps, но предполагается, что этим занимаются специалисты. И риск простоя проекта по причине ухода «ключевого» сотрудника снижается со 100% до скромных 10%. Как мы получили эти цифры? Мы опросили своих клиентов, и выяснили, что в случае ухода эксперта DevSecOps в течение месяца его не удавалось заместить лишь в 10% случаев. Значит, иметь технологию по безопасности – куда надежнее, чем «суперспеца», который «сам всё сделает».
- Ошибки можно устранять раньше. Ведь они неизбежны. А пентест или независимый анализ кода выявит недостатки, и их все равно надо будет устранить. Однако, делать это в процессе разработки – весьма болезненно для команды. Например, мы собрали статистику по своему проекту – MEDOED, где есть специалисты разного профиля. Выяснилось, что устранение ошибок в коде сразу после их написания занимает втрое меньше времени, чем если ликвидировать их раз в год. Сколько это стоит, каждый может посчитать сам.
Попытки регулирования: вред или польза?
Если с плюсами и минусами более-менее понятно, то вот подходы к безопасной разработке для многих – темный лес. И если best practice кое-как ищутся, внедряются, передаются из уст в уста, то со стандартами и даже требованиями ситуация довольно мрачная.В РФ есть ФСТЭК и ЦБ, которые выпускают различные (не всегда согласованные, но все же неплохие) требования к безопасной разработке. Это и ГОСТ 56939 с последними проектами изменений, и ГОСТ 15408 с небезызвестным ОУД4, и даже приказы о сертификации.
Однако, вводимые через «не хочу» требования приводят к печальным результатам: безопасная разработка есть, но только на бумаге. При этом в организациях, где DevSecOps уже существовал, даже такие жесткие требования, как профиль защиты от Банка России выполняются относительно безболезненно.
То есть те, кто задумывался о безопасности, требования выполняют. А те, кому важно лишь выполнять требования, не получают безопасности. Причем зачастую создать формальную видимость соответствия, но не трогать разработчиков, стоит дороже, чем реально привести процессы в порядок.
Вот такой парадокс, в условиях которого крайне рекомендуем начинать всегда не с комплаенса, а с повышения реальной безопасности процесса разработки. Тогда и «бумажные» требования автоматически подтянутся.
Так кому же полезна безопасная разработка?
Итак, если вы заинтересованы в том, чтобы выпускаемые релизы ПО были безопасны, и при этом не хотите тратить деньги, время и нервы на подрядчиков, то DevSecOps – ваш выбор. Бюджет на внедрение будет компенсирован экономией на аутсорсинге, а снижение производительности составит не более четверти.Если же ваш продукт не требует безопасности (это может быть простой графический редактор), то буквы Sec можно убрать и ограничиться DevOps. Как и в случае, если вас не слишком беспокоит защита данных ваших клиентов.
В заключение отметим, что проекты, в которых участвуют три разработчика, явно не имеют бюджета на безопасность. По нашим наблюдениям, окупается DevSecOps в командах от 10 человек, именно на таком объеме он выгоден экономически.
