Что самое сложное в проектной работе? Возможно, привести ожидания от процесса и результата заказчика и исполнителя к общему знаменателю.
Когда мы начали внедрять безопасную разработку в группе приложений ГК (кассовое программное обеспечение) крупного ритейлера, у нас было много времени на входе и задача по уменьшению уязвимостей в коде.
Но ниже мы расскажем, что и как нам пришлось решать на практике.
Кстати, это уже третий пост, в котором мы делимся опытом построения безопасного процесса разработки для крупного ритейлера.
Если вы пропустили, то можете прочитать первые две части: о безопасной разработке порталов и мобильных приложений И о безопасной разработке в группе SAP Applications. 
о проекте
С этой сферы мы начали, когда пришли к заказчику.Согласно стартовому плану проекта, у нас были достаточно гибкие сроки его реализации.
Мы были очень рады, наивно полагая, что сможем управлять несколькими проектами одновременно.
В итоге мы почти все время потратили на программное обеспечение кассового аппарата, потому что все оказалось гораздо сложнее.
В общем, это стало самым сложным направлением интеграции, поскольку требовало самой серьезной автоматизации процесса.
Во-первых, мы имеем дело с мощной бюрократической машиной.
Каждое действие требовало постоянных согласований, поправок, отчетов, их исправлений, запросов, ожидания ответов и получения разъяснений, что меняло подходы и требовало серьезных трудозатрат. А во-вторых, потому что у представителей заказчика не было ни желания, ни времени нам помогать.
ГК
ГК — это, по сути, фреймворк, на основе которого можно создать собственную настройку кассового программного обеспечения.Несколько лет назад заказчик купил у GK часть исходного кода этого программного обеспечения для создания своей собственной версии, поэтому в этом направлении работала очень большая группа разработчиков.
Большая часть программного обеспечения написана на Java (90% проектов).
Были также проекты, написанные на C++ с использованием довольно древних библиотек, поскольку аппаратное обеспечение было заточено под этот технологический стек.
Для Windows — для Windows Server 2008 и для набора библиотек для Visual Studio, для которых данная версия ОС была последней совместимой.
У группы были свои строгие процессы разработки, свои циклы выпуска.
Процесс ветвления был аналогичен Gitflow с основной веткой разработки и ветвями функций для различных задач.
Однако функциональные ветки могли месяцами находиться в состоянии разработки (часто готовые к объединению, но заброшенные) и объединяться прямо перед выпуском, в который они должны были быть включены.
Помимо реализации в CI/CD, мы реализовали и в Jira, для чего пришлось создать отдельную сущность для классификации «уязвимых» задач.
Этот тип задач позволил нам создавать уязвимости внутри Jira в соответствии с процессом разработки и работать с трекером задач.
Направление ГК имело длительный процесс разработки, когда под какой-то функционал создается фича, а потом эта ветка фичи может очень долго жить отдельно от основной ветки разработки.
Его можно проверить, но нельзя включить в мастер или разработку почти до релиза из-за технических сложностей регрессионного тестирования и т.п.
Интеграционное решение
Когда мы пришли в группу ГК для реализации Solar appScreener, то были удивлены огромным количеством кода в проектах этого направления и предложили стандартный вариант сканирования основной ветки разработки.Разработчики заявили, что тоже хотят получать информацию об уязвимостях и тоже хотят использовать анализатор, но не так, как силовики.
Им нужна была автоматизация тестирования уязвимостей: единая точка входа в виде GitLab, где они могли бы видеть все изменения.
Чтобы код не только основной ветки разработки, но и всех побочных веток автоматически запускался на сканирование.
При этом нам нужен был автоматический запуск от Jira и по желанию заказчика полуавтоматический запуск от Jenkins и GitLab. В результате мы решили, что самый простой способ анализа ветки (особенно для «длинных» фиче-веток) — запустить сканирование таким образом, чтобы задача в Jira при ее полном завершении (final push) была переведен в статус на рассмотрении.
После чего она обратилась к специалисту, который мог принять изменения и дать добро на начало сканирования кода на наличие уязвимостей.
В противном случае анализ кода каждого пуша разработчика в репозитории создал бы адскую нагрузку как для людей, так и для оборудования.
Разработчики фиксировали код в репозиторий не реже одного раза в пять минут, при этом проекты иногда содержали 3,5 миллиона строк кода, одно сканирование которых, соответственно, длилось 6-8 часов.
Это невозможно покрыть никакими ресурсами.
Стек технологий
Теперь немного о том, какой набор технологий использовался в проекте.GitLab как система контроля версий, Jenkins как система CI/CD, Nexus как хранилище артефактов и Jira как система отслеживания проблем.
При этом сами разработчики взаимодействовали только с Jira и GitLab, инженеры — с Jenkins, а специалисты по безопасности — с Solar appScreener. Вся информация об уязвимостях в коде присутствовала в GitLab и Jira. Поэтому нам пришлось организовать процесс сканирования следующим образом: в Jira задача передавалась в рассмотрение через Jenkins, так как требовалась сборка.
Был целый стек плагинов и скриптов Jenkins, получивших вебхук от Jira. То есть, помимо задачи типа «уязвимость», нам пришлось еще создавать в Jira вебхуки, которые при изменении проекта в ГК отправлялись в Jenkins и требовали дополнительных действий по настройке и серьёзной доработке двусторонней интеграции.
.
Процесс был такой: когда проблема обновлялась в GK, Jira проверяла, соответствует ли проблема тому, что следует отправить Дженкинсу, а именно, является ли она проблемой разработки.
И только после этого вебхук отправился к Jenkins, который разобрал вебхук и по телу запроса понял, какой репозиторий в GitLab и какую группу заданий следует запустить.
Разработчики ГК выдвинули ряд требований при создании задач в Jira, и мы постарались использовать их в полной мере, чтобы получить максимальное количество информации.
Благодаря этому мы смогли правильно сопоставить репозитории в GitLab и ветку, которую нам пришлось вытащить из конкретного репозитория, чтобы запустить его на анализ.
В требованиях мы строго прописали, что ветка в GitLab должна содержать в заголовке номер задачи в Jira. В принципе, это лучшая практика, которая используется повсеместно — сама задача должна иметь метки, указывающие, к какой части приложения/системы относится проблема.
На основе вебхука, который содержал название проекта, метки, поля с компонентами, а также ключ самой задачи и т.д., автоматически определялась необходимость запуска всех задач.
Некоторые проекты получили ответ всех «удовлетворительных» значений и затем были отправлены на сканирование.
А именно: был получен запрос в GitLab, проверено наличие этой ветки разработки, и при подтверждении система начала сканирование новой части кода этой ветки в Solar appScreener.
Мы учитываем ваши пожелания
Кадр из мультфильма «Вовка в тридевятом царстве».
Поскольку в проектах GK были десятки тысяч уязвимостей, разработчики не хотели видеть их все.
При этом код иногда содержал критические уязвимости: вставленные в код пароли, отражение межсайтового скриптинга, SQL-инъекции и т. д. Разработчики планировали исправить уязвимости в бэклоге и в первую очередь хотели увидеть изменения: то есть уязвимости, появившиеся в новом коде по сравнению с кодом предыдущей версии.
Однако механизмы, реализованные в нашем продукте, не предполагают инкрементного анализа для Java: анализируется байт-код, а проверить только измененные файлы невозможно, поскольку теряется связность кода.
Если один файл изменить, используя несколько библиотек или других пакетов, принадлежащих одному исходному коду, то вся информация об уязвимости теряется.
Поэтому мы сразу указали заказчику, что в этом случае можно анализировать только весь исходный код, и предложили следующую схему.
Как и для других проектов компании, для GK мы сопоставили проект в GitLab с проектом в Solar appScreener, а также дополнительно провели корреляцию с веткой разработки.
Чтобы разработчикам и ИБ-специалистам было проще искать, мы создали файл с реестром названия группы репозиториев, конкретного проекта из этой группы и ветки в Solar appScreener. Кроме того, разработчики хотели сразу видеть комментарии к изменениям в GitLab, и вот как мы это сделали.
Интеграция с GitLab
Сначала мы просканировали основную ветку разработки для каждого репозитория, из которого возникла ветка изменений.Поскольку разработчики хотели видеть комментарии с изменениями сразу в GitLab, мы договорились, что если ветка переведена в статус на рассмотрении, это означает, что уже есть соответствующий мерж-реквест на ее мерж.
Система проверяла, что мерж-реквест действительно открыт, и если это подтверждалось, то Solar appScreener анализировал основную ветку разработки.
Затем он просканировал ветку с изменениями, построил дифф, залил его, получил только новые уязвимости, взял из них критические (наш инструмент позволяет настроить уровни критичности) и преобразовал их описание в формат текстового сообщения с ссылка на эту запись в конкретном проекте в Solar appScreener (см.
скриншот ниже).
Эти сообщения были отправлены в GitLab в качестве обсуждения от имени технического аккаунта.
В мерж-реквесте вместе с измененным кодом можно было увидеть непосредственно строку триггера.
Оно сопровождалось комментарием на GitLab, адресованным конкретному разработчику, типа «здесь есть уязвимость, пожалуйста, исправьте или закройте ее».
Таким образом, между этими двумя сканированиями мы выявили изменения, которые внес разработчик.
Если количество уязвимостей росло, это обязательно отражалось в комментариях к отчету.
Такая схема оказалась очень удобной для всех участников, поскольку в GitLab сразу появлялись неразрешенные обсуждения, а значит, добавить мерж-реквесты нельзя.
И человек, ответственный за одобрение мерж-реквеста, увидел, что разработчик внес уязвимости и их нужно закрыть.
Интеграция с Active Directory
Для просмотра уязвимостей через Solar appScreener разработчикам нужны были права.Поэтому, помимо всей интеграции с системами разработки и всеми тремя областями, мы также интегрировались со службами Active Directory. Некоторую сложность для нас представляло то, что у заказчика был чудовищно большой AD с миллионом вложенных групп, что требовало множества оптимизаций.
То есть, помимо внедрения CI/CD, нам пришлось в процессе решить множество сопутствующих задач по настройке, адаптации и оптимизации (см.
скриншот ниже).
Что касается интеграции с Active Directory, то разработчики GK не захотели настраивать параметры доступа для ряда проектов Solar appScreener непосредственно в AD, поскольку ресурс им не принадлежал.
В компании процесс выдачи прав доступа выглядел так: если в разработке требовалось добавить в группу нового человека, нужно было написать запрос в техподдержку.
Там определяли, кому именно отправлять этот запрос, кто отвечает за выдачу таких прав, реально ли выдать права этому человеку, авторизованы они или нет и т.д. Это трудоемкий процесс, с которым разработчики не справились, в отличие от GitLab. Поэтому они попросили организовать интеграцию с AD следующим образом.
Они позволяют увидеть уязвимости не только техническим владельцам системы и специалистам по безопасности, как это было сделано для других областей, но и сделать сопоставление прав в GitLab. То есть, если человек имеет права разработчика или выше (мейнтейнер, владелец репозитория), то он может просматривать в Solar appScreener соответствующие проекты, принадлежащие этому репозиторию.
Когда в Solar appScreener создавался новый проект, система запрашивала имена всех участников GitLab в этом репозитории с уровнем доступа выше разработчика.
Список был выгружен, отправлен запрос в анализатор кода, который в свою очередь отправил запрос в AD с добавлением списка выбранных людей.
Все, кто был участником этого репозитория в GitLab, через свои учетные записи AD получили автоматические права на доступ к проекту в Solar appScreener. В конце всей цепочки формировался PDF-файл с отчетом об уязвимостях от анализатора кода.
Отчет содержал разницу, которая была отправлена списку пользователей проекта GK по электронной почте.
Краткое содержание
Реализованная интеграция с кассовым программным обеспечением ГК — это пример очень масштабного проекта внедрения и автоматизации процесса безопасной разработки в компании, который был построен не только вокруг службы информационной безопасности, но и вокруг разработчиков.Причем в этой группе проектов, как и в других группах, параллельно проводились сканирования основной ветки разработки: силовики также вводили задачи в Jira и проверяли их.
Уязвимости были добавлены в бэклог и позже исправлены.
Разработчики получили удобный инструмент, встроенный в привычную среду и рабочий процесс.
Поскольку они выбрали порог наиболее критических уязвимостей, которые встречаются довольно редко, их рабочая нагрузка после внедрения не сильно увеличилась.
В результате остались довольны все участники проекта: и те, кто стремился повысить безопасность кода, и те, кому пришлось исправлять уязвимости.
Если у вас есть собственный опыт внедрения практик безопасной разработки, поделитесь им в комментариях! Напомним: это третья часть серии статей о построении безопасного процесса разработки в крупном ритейлере.
В следующем посте мы подведем итоги работы над этим масштабным проектом: расскажем о том, чему мы научились в процессе, и как благодаря этому опыту развился наш инструмент. Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем Теги: #информационная безопасность #Программное обеспечение #Управление продуктом #уязвимости #ci/cd #gitlab #devsecops #Perfect code #анализ кода #Jira #active каталог #Active Directory #безопасная разработка
-
Важность Резервного Копирования
19 Oct, 24 -
Арамейский
19 Oct, 24 -
Вандрис, Джозеф
19 Oct, 24 -
Angularjs Против Knockoutjs
19 Oct, 24
