Как научить разработчиков писать безопасный код, ускорить создание продуктов и при этом сэкономить? Ответ — Application Security.

Давайте знакомиться

Наша команда занимается построением процессов DevSecOps. Цель — сделать так, чтобы клиенты Positive Technologies регулярно релизили качественное и безопасное ПО. Вроде бы звучит просто, но за этими словами кроется большой пласт задач: оценка процессов разработки, развитие и внедрение культуры (гигиены) ИБ, обучение сотрудников, внедрение и сопровождение инструментов и т. п.

Не буду утомлять долгими рассказами про свой «обширный многолетний опыт». Просто скажу, что делала проекты по безопасной разработке, когда слово DevSecOps еще заставляло людей краснеть и приравнивалось к WebCam’у :)

Статьи, где я делюсь своим опытом безопасной разработки, можно найти в журнале Positive Research.

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

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

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

Почему мы путаемся в терминах

Сразу ответим на вечный вопрос: нет, Application Security и DevSecOps — это не «те же яйца…» :) Рынок все еще не понимает, кто такие «аппсеки», «девсекопсы», аналитики по безопасной разработке и т. п. Иногда их просто называют «безопасники», а могут и вовсе объединять с разработчиками. Ориентируйтесь на то, что DevSecOps — это, простите за выражение, «нашлепка над DevOps». Понятие AppSec шире, в него входит множество инициатив и направлений, в том числе пайплайн DevSecOps.

Рисунок 1. Взаимоотношения AppSec и DevSecOps

Теперь к конкретике:

• AppSec-аналитики: определят путь развития компании в части безопасной разработки, проанализируют регуляторику и выберут оптимальные инициативы. К примеру, разбор результатов сканирования — это задача AppSec-специалиста. Причем он может называться и аналитиком, и инженером, и исследователем — суть одна.
• DevSecOps-инженеры отвечают за безопасный пайплайн. Как встроить те или иные инструменты в Jenkins, по какому триггеру они запускаются, куда будут выгружаться результаты и т. п.

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

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

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

Рисунок 2. Заинтересанты Application Security

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

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

Рисунок 3. Ценность Application Security

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

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

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

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

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

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

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

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

Рисунок 4. Различные требования к безопасной разработке

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

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

Как внедрять

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

Рисунок 5. Оценка уровня зрелости компании с точки зрения безопасной разработки

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

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

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

Рисунок 6. Окупаемость DevSecOps на примере платформы GitLab

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

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

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

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

Будьте готовы к тому, что специалисты по DevSecOps — это что-то редкое и, соответственно, дорогое. Как был 1 эксперт на 1000 разработчиков (и то если повезет), так и остался. Поэтому и стоят они как опытные тимлиды-разработчики. К нам на собеседование приходил парень, который «мечтал собрать свой первый пайплайн» и попросил за это 300 000 на руки :)

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

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

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

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

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

Комьюнити AppSec

Я уже упоминала, что наша отрасль формировалась хаотично, поэтому и комьюнити получилось очень разношерстное. При этом его значение сложно переоценить! В России есть классные площадки и сообщества, например КиберОрда. Я активно поддерживаю их инициативы и стараюсь вносить свой вклад. Помимо того, существуют экспертные каналы в Телеграме, где люди не рекламируют бренды и продукты, а действительно делятся экспертизой: posidev, appsec journey (хе-хе, это мой, не могу же не порекламировать) и др. Наконец, есть GitHub-страницы с AppSec-контентом: awesome devsecops, sottlmarek и др.

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

Надеюсь, комьюнити продолжит развиваться и будет постепенно формировать на рынке культуру безопасной разработки!

Куда мы идем

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

1. Использование кросс-практик. Представьте: 1000+ дефектов, которые нашел ваш SAST, по триггеру окончания сканирования бежит проверять DAST. В итоге приносит список всего из 25 подтвержденных уязвимостей, а потом (тоже по триггеру) просит WAF подготовить меры митигации, чтобы не блокировать релизы. Звучит как что-то новое! Мы с коллегами завернули все это в кодовое название AppSec 2.0.
2. MLSecOps. Речь не об использовании ML-практик в инструментах для тестирования защищенности приложений, а именно о безопасной разработке и эксплуатации всего, что окружает ML. В нашей команде этим занимается отдельная группа MLSecOps. Ребята формируют методологию и наполняют технологии экспертизой. Например, мы учимся сканировать LLM и выдавать отчеты по уязвимостям, знаем, как проверить ваши приложения с моделями на секьюрность, и скоро даже сможем быть ко-пайлотом в безопасном использовании моделей.
3. Расширение QA-функций в сторону тестирования безопасности. У тестировщиков прекрасно получается решать задачи Application Security. Мы тоже про поиск багов и проблем, только с точки зрения ИБ.

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

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

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

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