Как перестать бояться и полюбить безопасную разработку

Сегодня сложно представить компанию с крутым софтом, которая еще не перешла на гибкую, автоматизированную и цикличную методологию разработки. Ведь делать нужно быстро, круто и максимально user-friendly. Это, конечно, хорошо, но любая автоматизация порождает целый ворох проблем с безопасностью. Машина их генерит, а человек решает. Причем чем проблем больше, тем меньше успевает сделать человек...

Чтобы как-то контролировать всеобъемлющую автоматизацию, рынок изобрел безопасную разработку. Столько статей написано про Application Security, столько докладов прочитано, инструментов сделано и продано, а слепые зоны все равно есть. Более того, поскольку направление появилось и развивалось довольно хаотично, где-то на стыке ИТ и ИБ, вопрос «Что же такое безопасная разработка?» до сих пор открыт. Это тот самый чистый и секьюрный код? Безопасные кубы, в которых крутятся ваши сервисы? Инструменты тестирования или детектирования? А может быть, это те приложения, которые еще не взломали (или о взломе которых вы пока не знаете)?

Я бы ответила так: Application Security — это процесс, который позволяет вам быть спокойными и богатыми :) Это перечень повторяющихся действий, которые неминуемо приведут к положительному результату: научат разработчиков писать безопасный код, ускорят создание продуктов, помогут сэкономить и, возможно, даже спасут репутацию вашей компании. Проще говоря, если у вас действительно классный отдел Application Security, вы крепко спите, а ваш продукт приносит деньги.

Кому это нужно

Разберемся с основными заинтересантами безопасной разработки:

• Как минимум это сама разработка. CIO/CTO и продакты, которые отвечают за качество приложений, customer success и частоту релизов.
• CDTO, ответственные за трансформацию бизнеса — автоматизацию, цифровизацию и сокращение ручного труда.
• CISO, которому важно, чтобы деньги компании не утекли через приложение, никто не сливал персоналку, а коммерческие тайны оставались тайнами.

Важный момент: если CEO и топ-менеджмент компании пока не видят ценности в AppSec, не спешите ее внедрять. Звучит не очень жизнеутверждающе, но для реализации инициатив безопасной разработки нужно выстраивать в компании определенную культуру и менять существующие процессы. Не стоит запускать заведомо провальные проекты — лучше сфокусируйтесь на том, как правильно донести до руководства их важность и ценность.

К счастью, в Application Security заинтересованы все (даже если сами об этом не знают). В походе «наверх» можно заручиться следующими аргументами (см. рис. 3).

Почему важно начинать с процессов

Итак, вам дали добро на построение Application Security. С чего начать? Конечно с процессов!

Однажды я объясняла важность процессного подхода в безопасной разработке через пример с камнями и песком. «Помните, что сначала нужно наполнять банку камнями покрупнее, затем галькой и лишь потом добавлять песок. Только так получится полностью ее укомплектовать». Так вот, в безопасной разработке камни и галька — это инструменты и правила, а песок — те самые процессы, без которых банка разобьется при малейшей тряске. Мы же этого не хотим, верно? ;)

На рынке есть масса фреймворков, методик, методологий и стандартов. Я попробовала разные пути внедрения AppSec, даже экзотику в виде гайдлайна Microsoft, написанного году так в 2012-м (хороший, кстати, материал с точки зрения процессов).

Исторически самым популярным решением был и остается BSIMM — фреймворк и модель зрелости от Synopsys. Ребята следят за запросами рынка, ежегодно обновляют свою методологию и наполняют ее свежими практиками. Я работала только с BSIMM около двух лет, правда крутила его так, как мне было удобно, и трактовала, как считала адекватным.

Другой распространенный вариант — фреймворк OWASP SAMM, который запал в сердечко всем, кто котирует комьюнити OWASP, и не только. Не могу сказать, что мне сильно нравилось с ним работать, но в целом было удобно. Среди больших плюсов этого фрейма отмечу бесплатный инструмент для оценки зрелости компании — этакий самоопросник, который в итоге выдает красивую (или не очень) столбчатую диаграмму. Что делать с этими данными дальше, зависит только от вашей фантазии.

Помимо популярных методик есть и менее разрекламированные решения, например от BSA. На мой вкус, они сделали лучший фреймворк — с кучей референсов, отсылок, примеров имплементации и эксплуатации. Плюс наладили историю связи активности и рисков.

Сегодня наша команда работает по принципу compliance-driven: все, чего хотят регуляторы, уже заложено в нашей методологии. Наверняка вы сталкивались с отдельными ГОСТ и другими стандартами, которые не до конца понимаете. И уж тем более не знаете, как их подружить… Что делать, если PCI DSS требует одного, ГОСТ 56939 — другого, а ОУД — третьего? Чтобы ваша голова не болела, мы разработали методологию, в которой учтены все распространенные стандарты и положения, причем в правильном порядке (см. рис. 4).

Как внедрять

С методологией определились, наступает момент внедрения. Пора приоткрыть завесу тайны и провести краткую экскурсию по нашей работе. Мы начинаем с оценки текущего положения дел и составления карты процессов as is (рис. 5). Этот «слепок» помогает понять, что и где сейчас идет не так. Затем вместе с клиентом определяем, к чему мы хотим прийти. К платформе, нашпигованной кучей инструментов и полноприводной автоматизацией? Или достаточно наладить процесс сканирования приложений в 2–3 командах? После определения хотелок формируем roadmap внедрения и расставляем важные реперные точки, в которых при необходимости будем корректировать процесс.

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

Сколько стоит безопасная разработка

Логично, что за безопасную разработку, как и за все хорошее в этой жизни, нужно платить. А сколько? Кому? И где можно сэкономить? Начнем с того, что в нашем случае действует принцип «не вкладываешь — не получаешь», поэтому чтобы хорошо сэкономить в будущем, нужно заплатить уже сейчас. Если что, это не только мое мнение :) Приведу более частный пример: умные люди из Forrester посчитали возврат инвестиций в платформы DevSecOps на примере GitLab (см. рис. 6).

Мы считаем несколько иначе, но цифры получаем похожие: большинство компаний выходят в плюс в течение года, остальным требуется до 2,5 лет. Есть, конечно, и кейсы с менее адекватными сроками, но это исключения.

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

В чем конкретно заключается экономия? В ускорении выпуска релизов, а также в сокращении трудозатрат на исправление проблем безопасности и устранение последствий инцидентов.

Итого: на ПСИ проблем нет, с регуляторами тоже, даже с пентестами все гладко (ну или сильно лучше, чем могло бы быть). Разве не звучит, как какой-то magic?

Отдельным пунктом идет использование open source. Помогают ли открытые решения сэкономить? Время снова задавать вопросы — в основном риторические, но все же :)

Помните, как пару лет назад начался тренд на импортозамещение, продолжением которого стала замена хороших технологий на «зато они бесплатные»? Казалось бы, все, что поддерживается крутыми специалистами из комьюнити, не может быть плохим... Но любой, кто пытался перейти с коммерческого SAST-решения на условный CodeQL, подтвердит, что трудоемкое внедрение и поддержка требуют постоянного вовлечения 5–6 специалистов сеньористого уровня. Посчитаете, сколько это стоит?

Второй вопрос: так ли мы хотим — и умеем ли — делать что-то свое? Многие компании уже пилят или собираются пилить собственные решения для *** (подставьте нужное). Обычно это выглядит как попытка заколхозить очередную опенсорсную технологию с иллюзией, что «это дешевле, чем купить вендорский продукт». К слову, чтобы допилить Defect Dojo до приемлемого состояния, требуется от 6 месяцев до года и 3–4 специалиста AppSec/DevSecOps на полной занятости! Совпадение Дешево? Не думаю!

Кроме того, многие наверняка помнят истории прекрасных OSS, которые со временем оказывались принадлежащими одному или нескольким вендорам. Здесь легко поймать риск: в итоге придется либо отказаться от уже привычного инструмента, либо все равно заплатить вендору. Конечно, вероятность не 100%, но все-таки есть, и немаленькая.

Само собой, коммерческие решения — тоже не панацея (наша команда является частью Positive Technologies, но мы vendor agnostic). Тем не менее у проприетарных продуктов есть важные преимущества: отлаженная техническая поддержка, актуальные базы уязвимостей, выделенные R&D-центры и т. п. В условиях нехватки специалистов это действительно ценно: вы сможете закрыть вопросы безопасности приложений малой кровью.

Куда мы идем

В конце 2023 г. я поиграла в оракула и в нескольких своих выступлениях обозначила тренды Application Security. Спустя полгода я убедилась, что была права ;)

1.    Использование кросс-практик. Представьте: 1000+ дефектов, которые нашел ваш SAST, по триггеру окончания сканирования бежит проверять DAST. В итоге приносит список всего из 25 подтвержденных уязвимостей, а потом (тоже по триггеру) просит WAF подготовить меры митигации, чтобы не блокировать релизы. Звучит как что-то новое! Мы с коллегами завернули все это в кодовое название AppSec 2.0.

2.    MLSecOps. Речь не об использовании ML-практик в инструментах для тестирования защищенности приложений, а именно о безопасной разработке и эксплуатации всего, что окружает ML. В нашей команде этим занимается отдельная группа MLSecOps. Ребята формируют методологию и наполняют технологии экспертизой. Например, мы учимся сканировать LLM и выдавать отчеты по уязвимостям, знаем, как проверить ваши приложения с моделями на секьюрность, и скоро даже сможем быть ко-пайлотом в безопасном использовании моделей.

3.    Расширение QA-функций в сторону тестирования безопасности. У тестировщиков прекрасно получается решать задачи Application Security. Мы тоже про поиск багов и проблем, только с точки зрения ИБ.

А что делать вам?

Я не умею писать красивые выводы, потому что всегда ставлю перед собой всего одну цель: после прочтения статьи читатель сам должен захотеть что-то изменить. Почти любой участник процесса разработки приложений так или иначе участвует в обеспечении его безопасности. Бизнес-аналитик может учесть требования, связанные с оценкой рисков; системный аналитик — требования к парольной политике; архитектор — использовать корректные принципы проектирования; а разработчик — подрубить хотя бы линтеры и контролировать код. Свой вклад могут внести даже те, кто на первый взгляд находится где-то далеко. Например, проектному менеджеру достаточно вовремя актуализировать документацию, а продакту — контролировать качество проверок на разных этапах. 

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