Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки Positive Technologies. Неформально нас называют DevOps-отделом, а наши ребята занимаются автоматизацией различных процессов и помогают программистам и тестировщикам работать с продуктовыми конвейерами.
В прошлой статье мы с коллегами рассказали, как наши инженеры внедряли анализатор защищенности кода PT Application Inspector в сборочные конвейеры продуктовых команд. Тогда мы предложили клиент-серверную архитектуру и методику внедрения анализатора в CI/CD-конвейер, чтобы максимально упростить работу инженерам по инфраструктуре и CI-инженерам. Если перед вашими инженерами стоит задача внедрения сканера PT Application Inspector — обязательно прочитайте прошлую статью.
А из этой статьи вы узнаете:
как организованы DevSecOps-процессы в нашей компании, как построена архитектура размещения сканера PT Application Inspector в CI-конвейере и как изменилась схема типовой сборки при добавлении сканирования;
что такое Security Gates, как группировать уязвимости по степени важности и как при помощи шаблонов сканирования настроить блокирование мердж-реквестов в GitLab;
как программисты работают со сборочным конвейером, как патчат найденные уязвимости и что поменялось для них в процессе разработки после внедрения сканирования кода в сборки.
Процессы DevSecOps в Positive Technologies
Начну с небольшого обзора концепции DevSecOps на примере схемы типового CI/CD-процесса в нашей компании. Так будет проще понять, какое место занимает сканер PT Application Inspector в этом процессе.
Общие CI/CD-шаги для всех продуктов остаются неизменными. Разработчик пишет код фичи или исправляет найденные ошибки (Developing), делает git-коммит, после чего запускается автоматическая сборка в GitLab CI (Unit-Testing + Building). Далее происходит автоматическое развертывание на тестовые серверы (Deploying) и выполняются функциональное и прочие виды автотестирования (Functional Testing). Затем сборка продвигается в релизный репозиторий на Artifactory (Promoting), после чего компоненты и инсталляторы публикуются на корпоративный сервер обновлений GUS и происходит их автоматическое распространение через FLUS-серверы в интернете (Publishing GUS/FLUS). После этого на инфраструктуре заказчиков выполняется установка или обновление продукта (Installing/Updating). За установленным продуктом ведется наблюдение и сбор метрик (Collecting telemetry), его сервисы мониторятся (Monitoring) и собирается обратная связь от пользователей (User's feedback). Затем процесс разработки повторяется.
На схеме выше я предлагаю рассматривать Security-процесс так же непрерывно, как и процессы разработки, развертывания, тестирования и доставки. Безопасность нужно обеспечивать соответствующими инструментами на каждом этапе производственного конвейера. В частности, все изменения в коде должны проверяться на наличие потенциальных уязвимостей и ошибок. Решение нашей компании, сканер PT Application Inspector, позволяет проводить анализ исполняемого кода — как статический, так и динамический и интерактивный. Помимо этого продукта у нас в CI/CD-конвейере используются и другие решения, например система выявления инцидентов ИБ MaxPatrol.SIEM и межсетевой экран уровня веб-приложений PT Application Firewall.
Я хочу подчеркнуть, что концепцию DevSecOps, то есть непрерывный и безопасный процесс разработки, можно развивать в компании, только опираясь на инициативу и интерес самих разработчиков. Если руководство закупит какие-то инструменты и «спустит их сверху вниз» — ничего не выйдет. Разработчики должны быть сами заинтересованы в инструменте, он должен им нравиться, а также быть удобен в использовании.
Как PT Application Inspector внедряли в Positive Technologies
Теперь расскажу, как внедрение сканера происходило у нас. Сначала появились заинтересованные программисты из разных команд, которые хотели автоматизировать проверку своего кода, а затем к ним подключились DevOps-инженеры, которым было интересно попробовать внедрить новый инструмент в сборки. Они провели эксперименты и сделали пилот на одном из проектов. В итоге это вылилось в инициативу по развитию направления DevSecOps внутри всего сборочного конвейера Positive Technologies.
В рамках этой инициативы нам было нужно разработать для DevSecOps-специалистов, CI-инженеров и в первую очередь для программистов компании методику использования PT Application Inspector в разработке ПО, а также определить метрики, которые критичны для сборочного процесса. Такая методика необходима для понимания того, как разработчики должны использовать сканер, на какие найденные уязвимости обращать внимание и как эти уязвимости должны влиять на выпуск релиза или даже блокировать его; как работать с ветками и мердж-реквестами, а также как DevSecOps-специалисты должны выстраивать инфраструктуру безопасной разработки и внедрять PT Application Inspector с нуля в производственные процессы.
Мы преследовали несколько внутренних целей:
Внедрить SAST/DAST/IAST-решение в сборочный CI-конвейер всех продуктов, что позволит находить уязвимости в коде на ранних стадиях разработки (реализовать концепцию shift-left).
Использовать анализатор защищенности для сертификации продуктов компании — все сертифицирующие лаборатории требуют отчет по статическому анализу кода. До этого нам приходилось использовать сторонние продукты.
Дать возможность команде продуктовой разработки PT Application Inspector обкатать свои решения на «домашнем полигоне», выяснить потребности «живых» программистов — основных пользователей сканера и CI-инженеров — основных внедренцев продукта в сборочный конвейер, а также скорректировать планы разработки инструмента в зависимости от полученной обратной связи.
Продолжить развитие направления DevSecOps внутри продуктового конвейера компании. PT Application Inspector относится к общей схеме DevSecOps, это один из удобных инструментов для CI/CD-конвейера. Мы хотели дать внутренним разработчикам в Positive Technologies действительно удобный инструмент, которым бы они сами хотели пользоваться, который упростил бы и облегчил их работу.
Архитектура PT Application Inspector в CI-конвейере
Легенда:
DevOps.BuildAgent — сборочный агент
Docker.Linux.AISA.Latest/TAG — все докер-образы клиента AISA, доступные по тегу
AI.Agent — агент сканирования
AI.Server — сервер PT Application Inspector
DevOps.GitLab — хранилище кода
DevOps.GitLab-CI — CI-система
DevOps.Artifactory — хранилище артефактов сборок и сторонних компонентов
Docker.Registry — хранилище докер-образов
Docker.Linux.AISA — артефакт сборки клиента AISA (рабочий докер-образ с клиентом)
AI.Shell Agent — клиент AISA, запущенный внутри докер-контейнера, работающий с API сервера PT Application Inspector
BuildAgent.Console — системная консоль сборочного агента
WorkingDirectory — рабочий каталог на сборочном сервере, где лежит исходный код, который будет отправлен на сканирование
Коротко напомню, какую мы выбрали архитектуру. Сервер и агенты сканирования PT Application Inspector размещены на отдельных виртуальных машинах. Запуск задания сканирования осуществляется в отдельных шагах на сборочных агентах GitLab CI. Исходный код из проекта на GitLab сначала выгружается на сборочный агент в рабочую директорию сборки, а затем передается для анализа через консольный клиент AISA на сервер и далее на агенты сканирования.
AISA — это аббревиатура от Application Inspector Shell Agent. Этот клиент умеет работать с API сервера PT Application Inspector. AISA запускается в отдельном докер-контейнере, который является своеобразной «оберткой» для клиента.
Докер-образы с AISA собираются CI-конфигурациями, которые поддерживают CI-инженеры нашего DevOps-отдела. После сборки образы выкладываются в docker registry на Artifactory. Благодаря поставке докер-образами сборочная инфраструктура компании не зависит от разработки клиента AISA.
Мы определили основные шаги методики внедрения сканера в существующие CI-процессы. Вот они:
Подготовка серверной части:
● установка и настройка сервера PT Application Inspector;
● установка и настройка агентов сканирования.
Подготовка клиентской части:
● организация релизного CI-цикла для клиента AISA (поставка докер-образом).
Подготовка проекта сканирования:
● на стороне сервера;
● через клиент AISA.
Работа с CI-системами:
● шаблоны сканирования в GitLab CI;
● метараннеры TeamCity;
● прочие средства (работа с CLI AISA).
Чтобы внедрить PT Application Inspector по этой методике в конвейер одного продукта и поддерживать его работу, потребуются силы одного-двух CI-инженеров средней квалификации.
Сборочный процесс с использованием PT Application Inspector
Наши продукты — многокомпонентные, есть в них и сторонние компоненты. Из компонентов, продвинутых по результатам тестов в релиз и допущенных на интеграцию, собирается бандл (инсталлятор) продукта. Процесс сборки любого продукта максимально шаблонизирован, а его типовые шаги выглядят, как показано на схеме. На одном из шагов в сборке код передается на анализ на сервер через консольный клиент AISA. Напомню, что мы рекомендовали встраивать анализ кода непосредственно в сборочные шаблоны, чтобы было проще тиражировать процесс.
Как изменился алгоритм типовой сборки с учетом новых шагов сканирования:
Сборочный агент в момент старта сборки запрашивает исходный код проекта на GitLab.
Исходный код проекта скачивается на сборочный агент.
Запускается скрипт build-on-server, и начинают выполняться по порядку шаги сборки. Этот скрипт — точка входа для разделения логики сборки и ее внедрения в CI-конвейер. Скрипт build-on-server пишут разработчики, так как знают логику компиляции своего продукта, а CI-инженеры вызывают его в шагах сборки в своей CI-системе.
В параллельном с основной сборкой режиме запускается легковесный клиент AISA. Он использует конфигурационный файл с настройками сканирования.
Код передается на сервер сканирования.
Сервер распределяет код между агентами сканирования, на которых запускается процесс анализа.
Выполняется сканирование кода проекта. Сканирование никак не мешает основному сборочному процессу, так как выполняется на отдельных серверах.
Результаты анализа сохраняются в базе данных на сервере сканирования.
AISA-клиент получает результаты сканирования со стороны сервера, и они становятся доступны в сборочном пайплайне.
Выполняется проверка правил Security Gates. Результатом проверки является значение Code Quality Status — это 0, если все условия правил выполняются, и 1, если одно или больше условий не выполняются.
Если Code Quality Status равен 0, тогда считается, что пайплайны сборки и сканирования завершились успешно. При значении 1 сборка может быть остановлена, а в логи — добавлены соответствующие записи о проблемах с безопасностью кода.
Артефакт сборки публикуется в хранилище на Artifactory. К артефакту могут быть добавлены некоторые метки качества.
Специальный бот публикует отчет по сканированию и результаты проверки правил Security Gates в пайплайне на GitLab CI и в мердж-реквесте GitLab. Команде разработки отправляется уведомление об успешной сборке, к которому прикладываются результаты сканирования.
Что мы улучшили в этом процессе:
Раньше мы предлагали запускать сканирование на том же агенте, где идет сборка. Сейчас научились запускать сканирование в параллельном режиме, вынесли шаги отправки кода через AISA и шаги сканирования в отдельный пайплайн GitLab CI.
Раньше приходилось запускать сканирование, ждать отчета по его результатам и лишь потом запускать сборку и публикацию артефакта — либо отправлять код на сервер PT Application Inspector и через некоторое время, заранее неизвестное, возвращаться туда и смотреть результаты. Но сейчас появились штатные механизмы GitLab CI, и мы вынесли сканирование в так называемые downstream pipelines, или дочерние пайплайны. Теперь сканирование запускается всегда, на каждую сборку, параллельно самой сборке и не мешая ее ходу.
Добавили бота, который оповещает письмом или в чат о завершении сканирования, умеет добавлять отчеты прямо в мердж-реквесты GitLab, но, самое главное, понимает формат отчета сканера и может блокировать мердж-реквест на основании заданных правил, так называемых Security Gates (по аналогии с Code Quality Gates от SonarQube).
Разработчикам теперь доступно несколько вариантов работы с ветками в git. В зависимости от того, релизная это ветка или фича-ветка, можно использовать различные наборы правил блокировки мердж-реквеста либо только информировать о потенциальных уязвимостях.
Security Gates: правила и группировки
Итак, что мы предлагаем для обеспечения непрерывной безопасной разработки, что такое Security Gates и как они используются для блокировки мердж-реквестов в GitLab.
Security Gates — это набор правил для проекта сканирования, которые указывают CI-системе, как группировать найденные уязвимости и как на них реагировать: блокировать сборку или мердж-реквест либо работать в режиме информирования.
В качестве дополнительной меры в сборочных конфигурациях можно настроить «бан» собранного артефакта в Artifactory — переименовывать его с суффиксом -BANNED после сканирования, если будет найдено слишком много уязвимостей, не проходящих ограничения Security Gates.
Сами правила описываются в обычном yaml-файле, состоящем из двух разделов:
threats mapping — отвечает за маппинг и соответствие терминологии критичности проблем кода самого GitLab (имена ключей) и терминологии критичности уязвимостей PT Application Inspector (значения ключей). Кроме того, для удобства работы в этом разделе можно сгруппировать уязвимости по типу. Например, сказать, чтобы GitLab сгруппировал уязвимости уровней Potential, Low, Medium от сканера и отображал их в группе проблем Info.
security gates — в этой секции задается количество уязвимостей для каждой конкретной группы критичности. Если сканер найдет в коде указанное число или больше уязвимостей, то мердж-реквест или сборка будут заблокированы. Если задать значение ноль, проверка количества для соответствующей группы выполняться не будет. Если нули заданы для всех групп, то сканирование фактически будет вестись в режиме информирования.
Правила Security Gates в обоих разделах должны быть согласованы со специалистами по информационной безопасности в компании. На время разработки фич в отдельных ветках эти правила могут быть смягчены, чтобы не мешать быстрой разработке. Но в момент влития кода в релизные ветки обязательно должны использоваться максимально жесткие правила.
В качестве основы для интеграции сканера кода мы решили взять вариант интеграции известного продукта SonarQube через штатный механизм GitLab — codequality. Мы посмотрели, как он внедряет свои сообщения в мердж-реквест, и спросили наших разработчиков, насколько им это удобно. Оказалось, что большинству такая «портянка» сообщений в треде мешает, особенно когда приходится работать с legacy-кодом, для которого замечаний бывает очень много. Кроме того, открывается страничка с сотнями сообщений небыстро.
Поэтому, когда мы работали над внедрением нашего сканера в сборочные процессы, то решили сразу позаботиться об удобстве программистов и сделать более удобное отображение рекомендаций по безопасности, в одном треде мердж-реквеста. Этот тред обновляется автоматически с помощью специального бота, написанного нашими CI-инженерами для интеграции AISA с GitLab CI.
Security Gates: проверки
Если уязвимости найдены, но проходят условия Security Gates, то в сборке специальный шаг Code Quality Status выставляется в значение 0 (Passed). В этом случае мердж-реквест не будет заблокирован, а в треде на GitLab программист увидит комментарий от бота с перечислением найденных (некритичных для данного набора правил) уязвимостей. Прямо в треде он сможет посмотреть, что это за уязвимости, либо перейти по ссылкам к полному HTML-отчету или в сборку на GitLab CI или TeamCity, если сборка была инициирована там.
Во втором случае, то есть если уязвимости найдены и не проходят условия Security Gates, —значение Code Quality Status выставляется в 1 (Failed) и мердж-реквест блокируется путем добавления ключевого слова Draft в его заголовок.
В комментариях от бота, кроме всей прочей информации, указывается причина блокировки, то есть текущий набор правил Security Gates для ветки, где идет сборка.
При каждом сканировании бот обновляет один и тот же тред на страничке мердж-реквеста: все уязвимости удобно группируются и отображаются в одном месте.
В сборки на TeamCity сканирование кода добавляется аналогичным образом через скрипты-«метараннеры», которые разработаны специально для использования с AISA-клиентом. HTML-отчет по сканированию возможно прикрепить штатными средствами TeamCity, разместив его на отдельной вкладке (Tab reports), которая настраивается внутри проекта с конфигурацией.
Самое главное, что из сборок на TeamCity можно точно так же пробросить информацию о найденных уязвимостях в мердж-реквесты в GitLab.
Теперь перейдем к тому, как работают правила Security Gates и как результат их проверки — Code Quality Status — блокирует выпуск наших релизов.
Security Gates: три режима работы
Мы спросили у наших разработчиков, какой бы они хотели видеть интеграцию сканера PT Application Inspector с их сборками. Их основное пожелание состояло в том, чтобы он не мешал оперативной разработке фич и не требовалось бы долгое ожидание скана и сборок. В идеале, чтобы сканирование вообще не мешало сборкам. Именно для этого мы решили запускать его в параллельном пайплайне на GitLab CI.
Наши CI-инженеры разработали три типа шаблонов сканирования, каждый для своего типа веток. В фича-ветках мы храним шаблоны, которые сканируют в режиме информирования. При влитии в мастер или релизные ветки мы используем на выбор шаблон с блокировкой или самый строгий шаблон.
Основные отличия шаблонов — в их влиянии на сборку и в глубине интеграции сканирования со сборочным пайплайном. Например, самый строгий режим сканирования при непрохождении правил Security Gates одновременно блокирует и мердж-реквест, и сам сборочный пайплайн.
Все шаблоны кастомизируются, и при настройке сборочного процесса в специальном файле конфигурации .gitlab-ci.yml можно выбрать различные варианты работы со сканером.
Security Gates: Information mode
Давайте посмотрим на шаги типового пайплайна сборки на GitLab CI, в которой использовался шаблон для работы сканера в информационном режиме (AI Information Mode).
Для примера, пусть сама сборка состоит из типовых шагов:
юнит-тестирование кода (Unit tests);
сборка или компиляция (Build);
публикация собранного артефакта сборки в некоторое хранилище (Upload to registry).
В GitLab CI в файл gitlab-ci.yml можно импортировать любые другие шаблоны через команду include. При подключении шаблона сканирования к основным шагам пайплайна сборки добавляются дополнительные:
запуск в параллельном режиме внешнего пайплайна сканирования (Start AI Scan);
отправка кода на сервер и запуск сканирования через AISA (AI-Scanning);
в случае любых проблем с инфраструктурой сканирования — отправка информации об этом на мониторинг (Send info);
по окончании сканирования — отправка отчета о найденных уязвимостях со сканирующего сервера в AISA и его добавление к пайплайну основной сборки (AI Scan Report);
проверка правил Security Gates, добавление результата проверки — Code Quality Status (0, Passed / 1, Failed) —к основному пайплайну;
отправка оповещения о результатах сканирования и сборки на почту или в чат (Send emails).
Важно отметить, что в информационном режиме сканирования результаты проверок не блокируют сборочный пайплайн и мердж-реквест.
Security Gates: Lock mode
Следующая схема (AI Lock Mode) — чуть более строгая. Она подключается к основной сборке аналогично, через включение (include) шаблона сканирования, и добавляет все те же самые шаги, что и в режиме информирования.
Основные отличия этой схемы от предыдущей в том, что в основной пайплайн сборки пробрасывается дополнительный статус: ожидание отчета по сканированию (running). Кроме того, в случае непрохождения правил Security Gates мердж-реквест GitLab в этой схеме может быть заблокирован. Основной сборочный процесс при этом не блокируется, и сборка может создавать и публиковать артефакты.
Security Gates: Strictest mode
И, наконец, третья схема (AI Strictest Mode) — максимально строгая. Кроме шагов, описанных в предыдущих схемах, в дочерний пайплайн добавляется новый шаг, разрешающий или запрещающий публикацию сборочного артефакта (Approve build). Таким образом, если будут обнаружены уязвимости, не проходящие проверки Security Gates, то будут заблокированы и основной сборочный пайплайн, и мердж-реквест. Дополнительно мердж-реквест может быть переведен в статус черновика (Draft).
Далее расскажу, в каких случаях мы применяем разные шаблоны.
Работа с ветками git для разных режимов Security Gates
В разработке у нас используется классический git-flow для работы с ветками:
master — ветка для стабильного кода;
develop — ветка для основной разработки и стабилизации кода из влитых фича-веток;
feature — в продуктовых командах работа идет параллельно над множеством фич во множестве таких веток;
release — у наших продуктов может быть одновременно несколько поддерживаемых релизов, поэтому используется несколько релизных веток.
При запуске сборки или мердж-реквеста из конкретной ветки вызывается тот шаблон сканирования, который лежит в этой ветке. Приведу примеры режимов работы сканера, которые можно использовать при мердж-реквестах из различного типа веток.
Мы рекомендуем:
В feature-ветках хранить и использовать шаблон сканирования в информационном режиме (Information mode). Тогда при мердж-реквестах между feature-ветками и при влитии в ветку develop само сканирование никак не будет влиять на сборочный процесс и разработка будет идти быстро. Однако при этом разработчики все равно получают максимально подробные отчеты и рекомендации от сканера PT Application Inspector.
В develop-ветке хранить и использовать самый строгий шаблон (Strictest mode), а также настраивать в нем самые строгие правила Security Gates. В этой ветке важно стабилизировать код и избавиться от всех возможных уязвимостей перед его влитием в релизные ветки. Этот шаблон пресечет любые попытки мерджа уязвимого кода в релиз, заблокирует мердж-реквесты и сами сборочные пайплайны, не даст опубликовать артефакт с уязвимостью в хранилище.
В release-ветках допустимо хранить менее строгий шаблон (Lock mode) и использовать его при мердж-реквестах в master, так как большая часть уязвимостей уже будет закрыта на этапе стабилизации в develop.
В master-ветке можно использовать сканирование в информационном режиме (Information mode), так как в этой ветке лежит стабильный, протестированный и проверенный код релизов, а значит, можно минимизировать проверки.
Демонстрация: Security Gates и мердж-реквесты
В апреле 2021 г. мы провели вебинар для программистов и DevSecOps-инженеров. На нем мы показали, как шаблоны сканирования и правила Security Gates функционируют вживую, как наши программисты работают с реальными проектами, делают мердж-реквесты с поиском уязвимостей в коде через Application Inspector и как исправляют найденные ошибки.
Open Source dohq-ai-best-practices
Все наработки для GitLab CI и TeamCity, схемы и рабочие шаблоны сканирования для PT Application Inspector мы выложили в Open Source в проект dohq-ai-best-practices под свободной MIT-лицензией. Там вы найдете:
Подробное описание и схемы для рекомендуемой нами методики внедрения сканера PT Application Inspector в CI.
Скрипты инсталляции для упрощения настройки серверной части PT Application Inspector.
Dockerfile для сборки AISA-клиента под Windows и Linux.
Шаблоны типовых пайплайнов для GitLab CI и метараннеры для TeamCity с возможностью блокирования мердж-реквестов и работающие в параллельном режиме с основной сборкой.
Что еще почитать по теме DevOps
По мере развития нашего CI мы делились идеями и наработками в корпоративном блоге на Хабре:
«Личный опыт: как выглядит наша система Continuous Integration» (2016)
«Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps» (2017)
«Моделирование производственных процессов в ИТ-компании» (2018)
«Управление хаосом: наводим порядок с помощью технологической карты» (2019)
«Личный опыт: как выстроить карьерный рост в отделе DevOps» (2020)
«DevSecOps: как мы внедряли PT Application Inspector в наш продуктовый конвейер» (2020)
«Как работает команда DevOps в Positive Technologies» (2021)
Если вас интересует тема кибербезопасности, следите за нашими вебинарами и новыми статьями в блоге компании. А на этом пока все. Ждем ваших вопросов в комментариях :)
Автор статьи: Тимур Гильмуллин — заместитель руководителя отдела технологий и процессов разработки в Positive Technologies. Отвечал за разработку архитектуры и методики внедрения PT Application Inspector в сборочные техпроцессы со стороны DevOps-команды, а также подготовку проекта Open Source.
Технический эксперт: Дима Рагулин — CI-инженер отдела технологий и процессов разработки. Отвечал за подготовку архитектуры и скриптов для интеграции PT Application Inspector с CI-системами и подготовку проекта Open Source.
Развивать идеи DevSecOps в большой компании невозможно без коллектива высококлассных специалистов. Выражаю огромную благодарность нашим коллегам: Стасу Антонову, Антону Володченко, Олегу Мачалову и Саше Худышкину за оперативную техническую помощь по вопросам внедрения, разработки и использования сканера PT Application Inspector, Вите Рыжкову и Алексею Жукову за экспертизу и помощь с подготовкой вебинаров, всем инженерам нашего отдела DevOps Positive Technologies за техническое сопровождение сервиса PT Application Inspector и помощь с его внедрением в компании, а также всем разработчикам сканера за прекрасный продукт :)
