Как внедрить РБПО и не сойти с ума
Привет, сообщество РБПО! Ранее в статье я рассказывала о том, какие подходы и инструменты мы используем в «Базисе» для реализации DevSecOps. Сегодня хочу показать ту же задачу, но под другим углом, и поделиться опытом выстраивания организационных процессов безопасной разработки. Он же — опыт хождения по заботливо разложенным граблям.
Началось все с того, что два года назад нашей команде была поставлена задача: внедрить разработку безопасного программного обеспечения (РБПО) в компании, силами многих команд разрабатывающей принципиально разные продукты — от платформ виртуализации и контейнеризации до средств защиты и резервного копирования. Задача эта возникла естественным путем — «Базис» появился в результате объединения нескольких компаний, у каждой из которых были свои представления о разработке вообще и о безопасной разработке в частности. Нужно было привести все к общему безопасному «знаменателю». Покупателями наших продуктов были банки, операторы связи, государственные органы и другие организации, серьезно относящиеся к безопасности инфраструктуры, поэтому не хотелось стать звеном в supply-chain атаке.
Культура, автономность и другие препятствия
Первое препятствие на этом пути было очевидным: у каждой команды разработки уже сложились свои процессы и своя культура. Одни собирают продукты в docker-контейнерах, которые сразу становятся дистрибутивами. Другие создают контейнер только в процессе сборки, забирая из него готовый артефакт. А третьи вообще не используют контейнеры, работая напрямую в нодах Jenkins. Перед нами был не просто зоопарк технологий, а зоопарк проверенных и привычных технологий, от которых никто не собирался отказываться. Поэтому вариант с тотальной унификацией мы отмели сразу, посчитав, что на этом этапе он обойдется слишком дорого — как в плане ресурсов, так и в плане командного духа.
Второе препятствие — автономность команд. Каждая команда была кросс-функциональной, привыкшей решать свои задачи с максимально возможной эффективностью. И это было бы отлично, если бы не одно «но»: команды создавали собственные решения — свои логи, свой мониторинг и т. д. — и тянули архитектуру в разные стороны. Своего рода микросервисный подход, только на уровне организации процессов.
Третье и, пожалуй, самое сложное препятствие — это несовпадение подходов команд не только на уровне инструментов, но и на уровне архитектурного мышления. Каждая команда развивалась в своем контексте и под свои продуктовые цели. Где-то ставка делалась на скорость релизов и легкость экспериментов — там архитектура получилась гибкой, но хрупкой. Где-то, наоборот, ключевым приоритетом была стабильность, и система обросла слоями проверок и ручных согласований.
У одних команд микросервисность была доведена почти до предела — десятки маленьких сервисов, каждый со своей отдельной сборкой. У других — монолит с собственным CI/CD-пайплайном, «заточенным» под конкретную инфраструктуру.
Все перечисленное в итоге породило «организационный микросервис»: каждая команда успешно оптимизировала свою часть, но вся система в общем потеряла целостность. При попытке внедрить тот или иной инструмент безопасной разработки всплывали противоречия. Где-то следовало внедряться в docker-образы, где-то — учитывать, что бессмысленно перепроверять весь продукт целиком, если не было изменений в коде, а сборки происходили часто. Только очередь на проверку создашь, а результаты не изменятся.
Стало очевидно, что вместо единой технологической платформы у нас конструктор — каждый блок сам по себе рабочий, но собрать из них что-то общее непросто.
Первые шаги к цели
Изначально казалось, что процесс можно сделать простым и понятным: команды пишут код, готовится документация, мы запускаем проверки кода и зависимостей. Но быстро стало ясно, что каждая итерация превращается в бесконечный цикл: находим ошибки, исправляем код, правим документацию, запускаем новые проверки...
Одновременно увеличилась нагрузка на команды. Разработчикам приходилось не только писать код, но и разбираться с инструментами анализа, просматривать результаты проверок, исправлять найденные уязвимости.
И без того непростую ситуацию усложняли растущие требования регуляторов и необходимость сертификации продуктов. Подробнее про сертификацию и связанные с ней сложности рассказывал один из моих коллег, поэтому останавливаться на этом не буду.
Формула «сертификация = РБПО = расходы» вырисовывалась все четче. Нужно было срочно усиливать команду, нанимать DevSecOps-инженеров и специалистов по AppSec, закупать дополнительное оборудование. И одновременно выстраивать процессы РБПО, не забываем.
Мы решили пойти по пути разумного роста, точечно усилив ключевые направления. В фаззинг-команду, которая изначально состояла из двух человек, добавили еще троих — теперь это полноценная пятерка специалистов, способная не только запускать тесты, но и выстраивать методологию и автоматизацию.
Параллельно заказали дополнительные серверы — под динамический анализ различных продуктов в разных конфигурациях, чтобы не тревожить инфраструктуру тестировщиков, и отдельный пул мощных машин специально под фаззинг. Так мы смогли разгрузить общие ресурсы, ликвидировали очереди, а заодно избавили тестировщиков от необходимости конкурировать за вычислительные мощности.
Сложности взаимодействия с разработчиками
Когда мы только начинали свой путь к РБПО, коммуникация с разработчиками была простой и неправильной. Мы отсылали им отчеты об уязвимостях, они кивали головами — «да-да, исправим»; на этом общение заканчивалось, а вот исправления начинались не всегда. Пришлось перейти от неформальных чатов к формализованным задачам в таск-трекере, а заодно добавить в этот процесс автоматизацию. До этого мы многое делали руками — копировали результаты анализа в файл, искали по базе CVE безопасные версии библиотек, составляли таблицы для разработчиков.
Но если в маленьких проектах, где уязвимостей немного, автоматическое создание задач работало хорошо, то в больших… В какой-то момент AppScreener нашел на одном из проектов сотни потенциальных проблем разного уровня критичности — от действительно опасных уязвимостей до стилистических замечаний. Утром разработчики проснулись и обнаружили на своей доске около 250 новых задач. Удивились ли они? О да. Были ли они довольны? Нет.
Пришлось срочно менять подход на «одна задача на репозиторий». Сейчас все найденные проблемы собираются в один тикет, группируются по типам и приоритету, сопровождаются рекомендациями по исправлению. Такой подход сделал информацию более понятной для восприятия и позволил разработчикам планировать исправления в рамках спринтов, а не тонуть в море мелочевки.
Однако вместе с этим выросла нагрузка на команду DevSecOps. Если раньше мы просто передавали результаты анализа, то теперь пришлось брать на себя ответственность за качество агрегированных отчетов: решать, какие уязвимости действительно критичны, как их приоритизировать, где добавить контекст и рекомендации. По сути, мы стали «фильтром» между автоматикой и разработчиками — не просто транслировали результаты сканирования, а превращали их в осмысленные задачи, вписанные в продуктовый процесс.
Такой подход потребовал не только времени, но и экспертизы: мы начали теснее работать с командами, понимать особенности их стеков и архитектуры, чтобы не навешивать «лишних» тревог. Так постепенно DevSecOps из функции контроля превратился в сервис партнерского взаимодействия — тот самый мост между безопасностью и разработкой.
Также нужно было структурировать общение с командами. Самый важный урок, который мы извлекли, — обязательно объяснять, зачем и что мы делаем. Чем меньше объяснений, тем больше сопротивление со стороны разработки.
Сейчас у нас есть четкий сценарий для встреч с командами. На них мы:
- объясняем ценность безопасной разработки, рассказываем про конкретные риски и их последствия;
- договариваемся о формате передачи информации об уязвимостях;
- составляем список людей, которых нужно добавить в соответствующие группы;
- обсуждаем, кого и когда будем «пинать» по просроченным задачам;
- выясняем особенности команды и адаптируем под них процессы.
Такие обсуждения помогают найти формат работы, который будет удобен именно этой команде.
Показательный кейс у нас получился с фаззингом. Сначала мы пошли очевидным путем — попросили разработчиков заняться фаззингом собственного кода. Логика простая: кто лучше разработчика знает, как «профаззить» свою же функцию?
Однако простое решение оказалось еще и неверным. Для многих разработчиков фаззинг был новой дисциплиной: нужны были знания об инструментах, генерации входных данных, правильной интерпретации результатов. А главное — это не входило в их приоритеты. У людей есть продуктовые задачи, дедлайны, релизы — и дополнительная активность, пусть даже важная, воспринималась как «еще одна обязанность сверху». В итоге фаззинг либо откладывался, либо выполнялся формально: запускались базовые тесты, прикладывался отчет — и на этом все.
Тогда мы решили пойти по пути специализации и создали отдельную мини-команду фаззинга — изначально всего из двух человек, но с четкой зоной ответственности. Эти ребята погрузились в инструменты, накопили экспертизу и начали выстраивать повторяемый процесс. Параллельно мы занялись автоматизацией фаззинга в CI/CD: чтобы он запускался сам, с минимальными настройками и без участия разработчиков.
Команды сначала отреагировали настороженно, однако вскоре вздохнули с облегчением. Разработчики перестали тратить время на непрофильную задачу, но при этом получали более качественные результаты: четкие отчеты, реальные баги, понятные рекомендации.
Постепенно наша группа выросла до пяти человек — теперь это не мини-, а полноценная команда, которая не просто «фаззит код», а развивает методологию, автоматизирует запуск и интеграцию инструментов, готовит типовые сценарии для разных стеков. Мы постепенно превращаем фаззинг из разрозненной активности в системную часть безопасной разработки.
Отдельно хочу отметить: не надо фаззить ради отчета, отчет не защитит от эксплуатации уязвимости. Не надо фаззить ради ФСТЭК, регулятору не нужен ваш фаззинг. ФСТЭК нужен безопасный и качественный российский продукт. А фаззинг — это просто один из инструментов, позволяющий к нему прийти.
Чем больше времени мы работаем над РБПО, тем яснее становится: нельзя внедрить процесс и забыть о нем. Наша задача — постоянно анализировать, что работает хорошо, а что нуждается в улучшении.
Например, с анализаторами мы прошли путь от простого предоставления доступа разработчикам до создания централизованного docker-образа и полноценной интеграции в процесс сборки.
Но ключевым моментом было то, что мы не просто сказали командам: «Вот вам инструмент, разбирайтесь сами». Мы сначала сами обкатали решение на нескольких разных пайплайнах. В итоге пришли к командам не с абстрактной идеей, а с готовым работающим решением. Это снизило порог входа и сопротивление изменениям.
Автоматизация коммуникаций
Сейчас процесс выстроен четко: настраиваем пайплайны, проверяем код, создаем задачи и оповещаем о них в чате. Нашлось место и для модных тенденций — теперь в нашей экосистеме работает уже два Telegram-бота, каждый со своей задачей.
Первого бота сделали DevOps-инженеры. Он следит за изменениями в задачах, созданных командой безопасности, и уведомляет нас о любых обновлениях — изменении статуса, добавлении комментариев или приоритета. Раньше мы тратили время на ручное отслеживание прогресса в таск-трекере, а теперь все приходит прямо в чат: кто что закрыл, что перешло в ревью, где появился блокер. Благодаря этому коммуникация стала прозрачнее, а обратная связь — быстрее.
Второго бота мы сделали сами, уже под нужды пайплайнов. Он подключен к системам анализа кода — в частности, к Svace и другим инструментам статического анализа. Его задача — следить за «здоровьем» самих анализаторов: если пайплайн упал с ошибкой, значит, анализатор не запустился, и тогда бот сразу сообщает об этом в общий канал. Раньше такие сбои можно было заметить только постфактум — когда анализ не прошел и данные не обновились. Теперь мы узнаем о проблеме сразу и можем оперативно починить процесс, не теряя результатов проверки. В результате мы перестали «гоняться за ручными апдейтами» и теперь фокусируемся на анализе и улучшении качества кода, а не на администрировании. За все время внедрения РБПО количество инженеров в нашей команде практически не увеличилось, хотя число проектов и объем проверяемого кода выросли в разы. И роста мы добились не числом, а автоматизацией — каждое улучшение, пусть даже в виде простого уведомления, экономит часы и снижает нагрузку.
Свои контейнеры мы также проверяем — как те, что входят в состав дистрибутивов, так и те, в которых непосредственно собираем код. Сейчас процесс частично ручной: необходимо указать ссылку на сборку, после чего нужный дистрибутив автоматически скачается, распакуется, все имеющиеся в нем образы проанализируются, а результат упадет в CodeScoring.
Изменение культуры
Главное достижение — это изменение отношения разработчиков к процессу. Если пару лет назад многие воспринимали безопасность как «еще одну бюрократическую штуку, которая мешает работать», то сейчас ситуация постепенно меняется. Не только из-за наших усилий, конечно, — количество хакерских атак и утечек данных растет, подобные происшествия стали чаще появляться в медиа.
На моменте сертификации мы начали думать по поводу того, какая у нас поверхность атаки и модель угроз. Так получилось, что не всегда поверхность атаки — это весь репозиторий. Либо несколько директорий в одном репозитории. Тогда мы взяли эту поверхность атаки, пришли к разработчикам, объяснили им, для чего это надо, и вместе решили задачу.
Все меньше становится тех, кто не знает, чего ожидать от проверок безопасности. Когда приходишь к команде и говоришь «пора исправлять уязвимости», разработчики уже понимают, что их ждет и как с этим работать. Безопасность постепенно становится частью корпоративной культуры, а не навязанной извне обязанностью.
В итоге мы добавили взаимопонимания там, улучшили процессы здесь и смогли за счет таких небольших шагов кратно увеличить количество проектов в работе и объем проверяемого кода без значительного увеличения бюджета. Это относится и к сертификации продуктов, и к внедрению безопасной разработки.
Результаты и перспективы
Сейчас мы продолжаем совершенствовать процессы, ориентируясь на требования регулятора и новый ГОСТ Р 56939-2024. Основная цель — не только соответствие нормативным стандартам, но и сертификация нашей разработки безопасного ПО. Мы взаимодействуем с отраслевыми экспертами и перенимаем их опыт. В частности, вместе с ИСП РАН и ведущими вузами исследуем заимствованные компоненты и находим дефекты в коде. Также мы сотрудничаем с НТЦ «Фобос-НТ» и получаем от них актуальный опыт в РБПО-практиках.
Но вернемся к тому, с чего начали, — к унификации. Она по-прежнему не является нашей целью, однако постепенно подходы между командами удалось выровнять. У каждой из них все еще остаются свои «погремушки» и привычные процессы, но где-то удалось унифицировать инструменты, где-то — просто договориться о совместимых форматах и правилах взаимодействия. Это не про насильственную стандартизацию, а про поиск общего языка, который позволяет сохранять автономность команд, двигаясь при этом в одном направлении.
Со своей стороны мы дорабатываем пайплайны, автоматизируем ручные проверки, ищем баланс между скоростью и качеством. И каждый день становимся немного лучше — в инструментах, в коммуникациях, в подходах. А главное — мы сохранили рассудок в процессе внедрения РБПО. И, кажется, даже научились получать от этого удовольствие.
Автор:
Наталия Дмитриевна Дуботолкова, Руководитель группы обеспечения безопасности приложений ООО «Базис».
