Почему безопасная разработка нужна не всем?

Никто не спорит, что безопасность программного обеспечения при современном уровне цифровизации безусловно важна. Но сторонники DevSecOps уверяют, что без внедрения этой методологии не обойтись сегодня ни одному разработчику. Так ли это? Или все же редко обновляемым приложениям можно обойтись регулярными тестами? Разбираемся в этой статье.

Как многие уже знают, безопасная разработка – это процесс. Он включает в себя проверки, дополнительные тесты, аналитическую работу и так далее. Конечная цель всех этих действий – снижение вероятности того, что в ПО появится уязвимость.

При этом формулы расчета такой вероятности даже если и существуют, то относятся к категории алхимии. Но есть вполне объективные метрики, по которым можно оценить безопасность приложения. Рассмотрим три наиболее простых:

Все эти метрики автоматически (!) должны считать показатели для каждого релиза (на разных этапах, разумеется). Если они достигнуты, можно передавать релиз на сборку. Если нет, необходимо устранить недостатки.

Вроде бы все выглядит очень понятно и даже не слишком сложно. А выполнение заданного уровня метрик может снизить вероятность взлома приложения до минимума.

И тут появляется первое «НО». Даже просто на расчет метрик требуются ресурсы. Начиная от специалистов по DevOps и DevSecOps, заканчивая расходами на анализаторы (которые чаще всего не бесплатны), а также непосредственно разработчиками – им помимо бизнес-логики необходимо уделять внимание и «чистоте» кода.

Мы занимаемся безопасной разработкой с 2019 года и набрали определенный пул клиентов, которые внедряли за это время соответствующие процессы и методики. Большая часть этих заказчиков – банки и другие финансовые учреждения. И можем поделиться некоторыми выводами и наблюдениями, касающимися снижения качества обработки информации, связанной с ИБ, в процессе разработки. Особенно интересно посмотреть на размер компаний.

Чтобы не раскрывать конкретные цифры, которые мы получили под NDA, будем выражать в процентах снижение скорости разработки в зависимости от типа приложения и численности команды при внедрении DevSecOps. Разумеется, влияние оказывают и такие составляющие, как корпоративная культура, общая загруженность разработчиков, нюансы технологического стека. Однако, определяющими факторами при прочих равных оказываются именно размер команды и тип приложения.

Снижение производительности мы считали в среднем увеличении интервалов между выходами двух последовательных релизов в течение года. Переходный период мы не учитывали, поскольку в нем снижение производительности бывает кратным.

Очевидно, что для крупных команд снижение менее существенно – ведь процессы выстроены лучше и работа гораздо лучше декомпозирована. Там, где каждый занимается своим делом, вероятность ошибки резко снижается. А вот почему веб-приложения с личным кабинетом на сайте меньше страдают от внедрения безопасной разработки? Просто потому, что к нему предъявляется меньше требований. Те самые метрики, что мы разбирали выше, имеют более щадящие значения.

Поэтому и получается, что DevSecOps, если он не «для галочки», – вполне безобидная (и не тормозящая процессы) технология с точки зрения бизнеса. Опять же, для серьезных компаний. Но отметим и то, что динамика снижения производительности положительная. Чем дольше работает команда в DevSecOps, тем меньше ошибок.

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

Вот явные преимущества внедрения процесса безопасной разработки:

Резюмируя: экономить важно вдумчиво. Лучше платить тринадцатую зарплату программистам и повышать их производительность за счет оперативного устранения ошибок, попутно сократив количество внешних пентестов (раз в год, а не раз в релиз). Это будет в итоге гораздо выгоднее, чем экономить на внедрении процессов безопасной разработки.

Если с плюсами и минусами более-менее понятно, то вот подходы к безопасной разработке для многих – темный лес. И если best practice кое-как ищутся, внедряются, передаются из уст в уста, то со стандартами и даже требованиями ситуация довольно мрачная.

В РФ есть ФСТЭК и ЦБ, которые выпускают различные (не всегда согласованные, но все же неплохие) требования к безопасной разработке. Это и ГОСТ 56939 с последними проектами изменений, и ГОСТ 15408 с небезызвестным ОУД4, и даже приказы о сертификации.

Все эти документы направлены на повышение безопасности ПО и его конечных пользователей, в первую очередь – банков и их клиентов.

Однако, вводимые через «не хочу» требования приводят к печальным результатам: безопасная разработка есть, но только на бумаге. При этом в организациях, где DevSecOps уже существовал, даже такие жесткие требования, как профиль защиты от Банка России выполняются относительно безболезненно.

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

Вот такой парадокс, в условиях которого крайне рекомендуем начинать всегда не с комплаенса, а с повышения реальной безопасности процесса разработки. Тогда и «бумажные» требования автоматически подтянутся.

Итак, если вы заинтересованы в том, чтобы выпускаемые релизы ПО были безопасны, и при этом не хотите тратить деньги, время и нервы на подрядчиков, то DevSecOps – ваш выбор. Бюджет на внедрение будет компенсирован экономией на аутсорсинге, а снижение производительности составит не более четверти.

Если же ваш продукт не требует безопасности (это может быть простой графический редактор), то буквы Sec можно убрать и ограничиться DevOps. Как и в случае, если вас не слишком беспокоит защита данных ваших клиентов.

В заключение отметим, что проекты, в которых участвуют три разработчика, явно не имеют бюджета на безопасность. По нашим наблюдениям, окупается DevSecOps в командах от 10 человек, именно на таком объеме он выгоден экономически.