Привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки Positive Technologies. Неформально наш отдел называют DevOps-отделом, мы занимаемся автоматизацией различных процессов и помогаем разработчикам и тестировщикам в нашей компании.

Я и мой коллега Дима Рагулин хотим рассказать, как инженеры нашего отдела внедряли сканер кода PT Application Inspector (PT AI) в сборочные процессы продуктовых команд внутри компании. Отмечу, что статья про архитектуру и интеграцию PT AI в CI, а не про работу с этим инструментом и не про поиск уязвимостей. Подробнее о функциональных возможностях PT AI вы можете узнать из вебинара.

Статья состоит из двух частей. В первой части расскажем, какое место PT AI занимает в наших технологических цепочках, дадим рекомендации по возможной архитектуре его внедрения в CI-конвейер. Это будет полезно DevOps-архитекторам и специалистам по внедрению решений в области безопасной разработки (DevSecOps). Вторая часть посвящена практическому внедрению PT AI в наш корпоративный CI-конвейер: в ней мы поделимся наработками своих шаблонов и скриптов, а также покажем, как можно подключить сканирование через PT AI в пару строчек кода. Это может быть интересно инженерам, перед которыми встали вопросы внедрения PT AI внутри уже сложившихся инфраструктуры и процессов разработки.

PT Application Inspector в технологическом конвейере

Чем занимаются DevOps-инженеры в Positive Technologies

Понятие DevOps включает в себя не только инструменты и сервисы разработки, но также методологии и лучшие практики их использования. Positive Technologies уже 18 лет разрабатывает продукты в области ИБ, а наш DevOps-отдел помогает анализировать, классифицировать и автоматизировать отдельные этапы разработки. Кроме того, мы шаблонизируем и тиражируем решения отдела в продуктовые команды.

Если обобщить, то мы поддерживаем весь CI/CD-конвейер от коммита строчки кода разработчиками до публикации готовых продуктов и лицензий на серверах обновлений и контролируем их доставку до инфраструктуры заказчиков. Также мы собираем и агрегируем  знания о CI/CD конвейере всех продуктов компании, делимся своими наработками и лучшими DevOps-практиками с командами.

Сейчас в отделе работает 15 инженеров. Мы работаем по сервисной модели и решаем заявки внутренних пользователей — 500++ разработчиков и тестировщиков компании. Ведём проактивную разработку и улучшение наших инструментов, исследуем, внедряем и развиваем полезные для разработки сервисы. Один из таких полезных сервисов — PT Application Inspector, о котором пойдёт речь в статье.

Наши продуктовые CI/CD-процессы технологически построены на нескольких взаимосвязанных системах:

• GitLab (хранилище кода), где размещено более 9.5K сборочных проектов;

• GitLab CI (основная CI-система), где выполняется более 2.7M сборок в год;

• Artifactory (в качестве хранилища бинарных компонент), где хранится более 8.2Tb артефактов;

• Сборочные агенты, сгруппированные по high, med и low пулам, в зависимости от требований к ресурсам. В пулах используется более 40 общедоступных виртуальных машин, размещённых во внутрикорпоративном облаке vSphere.

На базе этих систем уже в 2014 году был построен типовой CI-процесс, мы разработали скрипты для интеграции сборок любого типа и на любых языках программирования с корпоративной CI-системой, сделали сборочный конвейер для десятка продуктов компании.

По мере развития CI мы делились наработками в опенсорсе, на митапах и конференциях. Об этом мы писали в корпоративном блоге на Хабре:

• "Личный опыт: как выглядит наша система Continuous Integration" (2016).

• "Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps" (2017).

• "Моделирование производственных процессов в ИТ-компании" (2018).

• "Управление хаосом: наводим порядок с помощью технологической карты" (2019).

Польза PT Application Inspector для DevSecOps-направления

PT Application Inspector — инструмент для выявления уязвимостей и ошибок в приложениях, поддерживающий процесс безопасной разработки. PT AI использует статические, динамические и интерактивные методы (SAST, DAST и IAST), а по результатам анализа формирует безопасные эксплойты для ручной проверки наличия уязвимостей.

PT AI позволяет ИБ-специалистам выявлять и подтверждать уязвимости и признаки НДВ, например, закладок, оставленных в исходном коде разработчиками или хакерами, а разработчикам — ускорить исправление кода на ранних стадиях разработки.

Список поддерживаемых языков для сканирования: java, php, c#, vb, objective-c, c++, sql, swift, python, javascript, go, kotlin.

С недавних пор наш отдел помогает развивать в компании идеи DevSecOps. Методологии DevSecOps подразумевают обеспечение безопасной разработки на всех технологических этапах и шагах производственного CI/CD-конвейера. При этом контроль безопасности и разработка осуществляются параллельно, а инструменты, обеспечивающие безопасность, рекомендуется внедрять непосредственно в CI/CD-конвейер.

Анализатор кода PT Application Inspector  выявляет уязвимости на ранних стадиях разработки. Именно поэтому он хорошо ложится на идеи DevSecOps и мы воспользовались им на одном из этапов сборки продуктов. Инструмент гарантирует нам, что на продакшн попадут только релизы без уязвимостей.

Кроме того, PT AI помогает нашим инженерам в решении и других технических задач:

• Прохождение сертификаций. Проведение анализа кода на самых ранних стадиях жизненного цикла разработки ПО позволяет снизить риски ошибок при прохождении в испытательных лабораториях сертификаций продуктов компании.

• Оценка качества кода. В PT AI реализован не только поиск уязвимостей в коде, но и анализ его качества, например, использование устаревших и неподдерживаемых функций или пустые обработчики исключений.

• Поиск уязвимостей в исходном коде для различных языков. Анализатор поддерживает более десятка языков программирования и позволяет выявлять уязвимости с учётом особенностей используемых фреймворков и 3rd-party библиотек.

• Автоматическое блокирование выпуска уязвимых компонент. Использование PT AI в режиме Security Gate позволяет задавать правила для анализа и блокирования сборок продукта или его компонент при несоответствии результатов сканирования этим правилам.

Релизная схема сборок с продвижениями

Глобальная цель от внедрения идей DevOps в нашей компании — последовательное снижение себестоимости производства и сопровождения продуктов в количественных показателях (человеко-часах или машино-часах, CPU, RAM, Disk). Самый простой и очевидный способ такого снижения — минимизировать затраты на выполнение задач и тиражирование решений на всех этапах производства. Мы унифицировали все CI-проекты, создав так называемую релизную схему сборок с продвижениями, которая сейчас используется для всех продуктов компании.

Перед нами встала задача: внедрить в уже имеющиеся и сложившиеся сборочные процессы новый этап сканирования кода при помощи PT Application Inspector. Совместно с DevOps-инженерами, разработчиками PT AI и внутренними пользователями сканера кода — разработчиками из других продуктов — мы рассматривали несколько вариантов его "врезки" в CI-процессы релизной схемы:

• выполнять сканирование кода только протестированных компонент перед их продвижением в релизный репозиторий (перед этапом Promoting);

• выполнять сканирование кода релизных компонент перед их публикацией на серверах обновлений (перед Publishing);

• сделать сканирование кода как один из видов приёмочных тестов (внутри Testing);

• запускать сканирование кода до выполнения шага компиляции компоненты на этапе сборки (внутри Building, первым шагом);

• запускать сканирование кода после компиляции компоненты, перед выкладкой артефакта в хранилище (внутри Building, перед сохранением в Artifactory).

Каждый из этих вариантов имел плюсы и минусы. Например, сканируя код перед продвижением компоненты в релиз можно было минимизировать нагрузку на сканирующий сервер за счёт уменьшения количества сканов. Однако мы решили запускать сканирование кода до выполнения шага компиляции компоненты на этапе сборки. Этот вариант позволял достаточно легко внедрить шаг сканирования прямо в шаблоны сборочных конфигураций и быстро тиражировать это решение, что важно для CI-инженеров.

Мы написали несколько скриптов для запуска сканирования и сохранили их в DevOps-Tools (это внутренние инструменты, которые всегда доступны на сборочных агентах), а также подготовили для разработчиков несколько шаблонов типовых задач (job) для GitLab CI, с примерами параметризации и запуска этих скриптов.

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

Архитектура размещения PT Application Inspector Enterprise Server

Кроме вопроса, на каком этапе техпроцесса запускать сканирование кода, мы рассматривали различные архитектурные решения по размещению серверной части PT AI внутри сборочной инфраструктуры. Было несколько вариантов развернуть AIE-сервер:

• на каждом сборочном CI-агенте в хостовой ОС, а запускать проверку кодовой базы во время сборки прямо на этом агенте;

• в базовых докер-контейнерах, которые предоставляют CI-инженеры для сборок, и запускать сканирование из этих контейнеров;

• на отдельной виртуальной машине, передавать на сервер исходный код со сборочного агента во время сборки, проверять код удалённо и возвращать в сборку статус сканирования.

Плюсы первого и второго варианта, что сканирующий сервис сразу доступен на любом CI-агенте, не нужно долго передавать код и ждать запуск и результаты сканирования. Однако мы отказались от них, так как на инженеров по инфраструктуре тогда бы легло множество задач по обновлению серверов AIE во всех базовых докер-контейнерах и их мониторинг. Кроме того, серверную часть AIE на данный момент возможно установить и запустить только на Windows Server, а у наших продуктовых команд есть и Linux-сборки.

На схеме представлен третий вариант, на котором мы остановились.

Мы развернули серверную часть AIE (на схеме обозначено как Server.AIE.Agent) и сканирующие агенты на отдельных виртуальных машинах.

Исходный код (source code) из проекта на GitLab (DevOps.GitLab) сначала выгружается на сборочный агент (DevOps.BuildAgent) в рабочую директорию сборки (workingDirectory), а затем передаётся для анализа на сервер AIE через специальный консольный клиент Application Inspector Shell Agent или AISA (AIE.LightweightClient). Клиент умеет работать с API сервера AIE. AISA запускается в отдельном докер-контейнере (Docker.Windows/Linux.AISA-client), который является своеобразной "обёрткой" над клиентом.

Возможности передать код на AIE-сервер напрямую из GitLab-проекта, без физического копирования со сборочного агента ("стрелочка" от source code к AIE.Server), в текущей версии нет, но в будущих версиях AISA разработчики обещают такую возможность.

Докер-образы с AISA собираются специальными конфигурациями (DevOps.GitLab-CI), которые поддерживают CI-инженеры DevOps-отдела. После сборки образы выкладываются в docker registry на Artifactory (Docker.Registry). Для их подготовки мы организовали релизный цикл и приёмочное тестирование.

Благодаря поставке докер-образами сборочная инфраструктура компании не зависит от разработки самого клиента AISA.

Обновлённый сборочный процесс с использованием PT AI

Мы определились, что будем запускать сканирование кода до выполнения шага компиляции компонент на этапе сборки. Сервер AIE в нашей инфраструктуре будет размещён на отдельной виртуальной машине, а запуском сканирования и передачей кода на анализ будет заниматься консольный клиент AISA, "обёрнутый" в докер.

В качестве основной CI-системы мы используем GitLab CI, а все технологические шаги и этапы реализуем в виде шаблонов в файлах .gitlab-ci.yml. На схеме представлен обновлённый CI-процесс, который мы тиражируем внутри компании, с учётом новых шагов сканирования.

Основные этапы методики внедрения PT AI в CI

Для упрощения работы CI-инженеров мы подготовили небольшой список рекомендаций по внедрению и технической эксплуатации серверной, клиентской и CI частей PT AI. Эти рекомендации можно представить в виде шагов простой методики: подготавливаем серверную часть, организуем релизный цикл для клиента AISA, подготавливаем проект сканирования для AIE-сервера и начинаем работать со сканами в CI-системах.Первая рекомендация, на которую стоит обратить внимание: серверную часть Application Inspector Enterprise нужно разместить на отдельной виртуальной машине. Это упростит её настройку, обновление и мониторинг, чем если бы сканирующий сервер устанавливался на каждом сборочном агенте, либо подтягивался туда докер-образом. В отличие от клиента AISA, "оборачиваемого" в докер, с сервером мы так не делаем. По крайней мере до тех пор, пока AIE-сервер не будет официально поставляться как докер-образ.

Вторая рекомендация: поставляемые бинари клиента AISA необходимо "обернуть" в докер-образы, версионировать их и настроить релизный цикл с тестированием в вашей CI-системе. Это значительно упростит CI-инженерам распространение AISA-клиента по сборочной инфраструктуре и не придётся каждый раз устанавливать клиентскую часть на все сборочные агенты — образ будет подтягиваться из docker registry по запросу во время сборок. А также, при необходимости, можно будет быстро откатиться на предыдущие версии AISA простой заменой тега latest для докер-образа.

Все это было сделано для того, чтобы чётко отделить инфраструктурную часть PT AI от процесса разработки и сборки продуктов. Наши CI-инженеры отвечают за сборочную инфраструктуру, инфраструктуру сканирования и интеграцию с ней сборок, а разработчики должны иметь простую возможность подключить свой код на анализ, работать только с получаемыми от PT AI результатами и повышать безопасность и качество кода.

Далее рассмотрим техническую часть внедрения PT Application Inspector в сборочный CI-конвейер и тиражирование нашего решения со сканированием кода по продуктовым командам.

Компоненты решения: сервер, клиент и интеграция с GitLab CI

Серверная часть PT Application Inspector Enterprise

PT Application Inspector Enterprise Server — это сервис под Windows, который является агрегатором для сканируемого исходного кода. Анализ кода выполняется на специальных агентах сканирования (workers), которые получают задания от сервера аналогично, как и в CI-системах TeamCity, GitLab CI или Jenkins. Настройки проектов сканирования хранятся на сервере.

Для упрощения работы с серверной частью в нашем опенсорсе есть установочный скрипт. После установки доступ к сервису осуществляется через веб-интерфейс или через специальный софт Application Inspector Viewer.

Релизный CI-цикл для AISA-клиента

Относительно нашей сборочной инфраструктуры клиент AISA, который разрабатывает команда PT AI, является 3rd-party — внешним инструментом. Поэтому, прежде чем начать его использовать в CI-конвейере и ничего не поломать при этом, мы организовали для него стандартный релизный цикл сборки в докере, интеграционное тестирование на сборочной инфраструктуре и продвижение в релиз. После тестирования клиент возможно использовать в сборках других продуктов.

Первый этап релизного цикла для AISA включает в себя одновременную сборку двух докер-образов под Linux и Windows, установку в них новой версии клиента AISA и выкладку образов в корпоративный docker registry на Artifactory. В качестве тега для докер-образов мы используем текущую версию клиента AISA и дополнительный билд-номер сборки докера. Например, 3.6.1.4931-7 означает, что используется седьмая сборка докер-образа, внутри которого установлена версия AISA 3.6.1.4931.

Второй этап — маркировка докер-образов тегом latest. Для нас это означает, что образы можно "продвинуть" (promoting) из snapshot-репозитория в release-репозиторий и начать использовать в общем корпоративном сборочном конвейере. Но до того необходимо успешно пройти третий этап приёмочного тестирования, где проверяется возможность сделать docker pull образов из docker registry, тестируются различные способы запуска клиента внутри докера и насколько корректно он взаимодействует с текущей версией AIE-сервера. После тестирования докер-образы маркируются дополнительными атрибутами, с так называемыми метками качества, и уже потом их можно "продвигать" в релиз.

После продвижения докер-образы с новой версией клиента AISA доступны для использования в сборках продуктов. Клиент предназначен для того, чтобы отправлять исходный код на сервер AIE, а также он может создавать и настраивать на сервере проекты сканирования и получать по ним отчёты. Кроме клиента мы добавляем в докер различные вспомогательные утилиты.

Внедрение PT AI в GitLab CI

Мы показали архитектуру размещения AIE-сервера и шаги изменённого сборочного процесса, с учётом новых шагов сканирования. Этот процесс не зависит от CI-системы. Однако для простоты рассмотрим его пошаговую реализацию на примере шаблонов GitLab CI.

Сборочные шаги в GitLab CI описываются отдельными задачами (job) в специальном файле .gitlab-ci.yml. При запуске задачи на сканирование сначала происходит загрузка исходного кода на CI-агент. Затем, в зависимости от операционной системы, скачивается Linux или Windows докер-образ с клиентом AISA.

Для генерации проекта сканирования у нас используется утилита aisa-set-settings. Она создаёт специальный файл .aiproj с настройками проекта, которые AISA отправляет на сервер. Запуск утилиты не основная операция, поэтому мы разместили её в секции beforescript.

Основная секция начинается с запуска утилиты aisa и передачи ей необходимых параметров. В случае, если проект на AIE-сервере был заранее создан, можно использовать ключ --project-name для отправки исходного кода сразу в него. Если проект не существует, что чаще всего и бывает, то нужно использовать ключ --project-settings-file с указанием имени файла настроек проекта. AISA создаст проект на сервере и код начнёт сканироваться. При повторном запуске настройки обновятся.

Информация о ходе сканирования попадает в лог сборки и получить отчёт возможно в виде артефакта нужного формата, например HTML и JSON. Если не нужно ждать полного завершения скана, можно воспользоваться ключом --no-wait, с помощью которого работа AISA будет завершена сразу же после отправки исходников на сервер. Отчёты при этом получены не будут, но их всегда можно посмотреть через веб-клиент на AIE-сервере.

Остаётся вопрос с местом хранения файлов для настройки проектов сканирования. Их можно подготовить заранее и хранить в продуктовых git-репозиториях. Но для себя мы выбрали способ, который предлагаем и вам, — всегда генерировать файл с настройками через утилиту aisa-set-settings. В таком случае потребность в хранении файла отпадает и становится проще тиражировать шаги сканирования в сборочные шаблоны команд.

Мы разделяем шаблоны сканирования на две категории — базовые типовые и продуктовые. Они очень похожи, но несут в себе различную функциональность.

Базовые типовые шаблоны сканирования — стандартные, редко изменяемые, их сопровождают CI-инженеры. Эти шаблоны можно быстро и легко подключить в любых сборочных шаблонах. Они имеют минимальные настройки для начала сканирования кода.

Продуктовые шаблоны сканирования создаются под нужды конкретной команды разработчиков. Настройки в них можно кастомизировать: указать действия после получения отчёта, например, отправить его по почте или сохранить в хранилище для дальнейшего анализа, запустить внешнюю утилиту aisa-codequality и экспортировать отчёт в мерж-реквест для GitLab или выполнить любые другие сценарии разработчиков.

На следующем скриншоте можно увидеть ключевое решение, ради которого всё и затевалось, — тиражирование шаблонов сканирования в продуктовые шаблоны "в пару строчек кода". Здесь указана достаточно простая конструкция: в сборочном проекте подключаем через include ссылку на шаблон сканирования и задаём необходимые переменные, в частности, основной язык программирования. Подключаемый шаблон должен находиться в публичном репозитории на GitLab.

Сам процесс сканирования и получения отчетов от PT AI не требует от наших разработчиков понимания того, как работает инфраструктура сканирования и PT Application Inspector. CI-инженер или сами программисты вставляют одну строчку кода — "а дальше оно само".

Для интеграции PT AI с CI-системой TeamCity можно использовать так называемые метараннеры. Разработанные для внедрения PT AI метараннеры под Linux и Windows при помощи python-скрипта выкачивают нужный докер-образ с клиентом AISA и он запускается с заданными аргументами.

Open Source dohq-ai-best-practices

Всю документацию, схемы и наработки для CI мы выложили в опенсорс в проект dohq-ai-best-practices под свободной MIT-лицензией.

Там вы найдёте:

• подробное описание и схемы для рекомендуемой методики внедрения PT AI в CI;

• скрипты инсталляции и рекомендации по настройке серверной части PT Application Inspector Enterprise;

• примеры dockerfile для сборки AISA-клиента под Windows и Linux;

• примеры шаблонов для шагов запуска сканирования кода через AISA:

  • job-ы для GitLab CI,

  • метараннеры для TeamCity,

  • команды для работы с CLI AISA.

Этим опенсорс-проектом мы хотели обобщить все знания и навыки наших DevOps-инженеров, полученные при внедрении и эксплуатации PT Application Inspector внутри компании, а также дать рекомендации, как можно упростить внедрение сканера кода в сборочные процессы, построенные на базе любой CI-системы. Ваши инженеры могут без ограничений воспользоваться этими наработками.

Вебинар

В начале декабря 2020 наша компания проводила вебинар для CI-инженеров, инженеров по инфраструктуре и специалистов DevSecOps по теме внедрения PT Application Inspector. Мы рассказали и показали, как развернуть и эксплуатировать PT AI в сборочном конвейере с учетом особенностей корпоративной инфраструктуры (можно посмотреть только демонстрацию решения на 39:45).

Из него вы узнаете: что умеет PT Application Inspector "из коробки", о способах его интеграции в процессы разработки, в том числе, как подготовить серверную часть Application Inspector Enterprise и как удобно настроить взаимодействие с сервером при помощи клиентской утилиты AISA. На вебинаре даны рекомендации для DevSecOps-инженеров по работе с AIE-сервером и AISA. Особенно полезно это будет тем инженерам, которые уже внедряют PT Application Inspector в сложившиеся инфраструктуру и процессы разработки в своей компании.

Ссылки

Упоминаемые в статье ссылки:

• PT Application Inspector Анализатор и сканер кода для поиска уязвимостей: ptsecurity.com/ru-ru/products/ai/

• Записи вебинаров Positive Technologies:

  • про инструмент PT Application Inspector: ptsecurity.com/ru-ru/research/webinar/pt-application-inspector-obzor-novoy-versii-i-roadmap/

  • про внедрение PT Application Inspector в CI-процессы: ptsecurity.com/ru-ru/research/webinar/devsecops-vnedrenie-v-produktovyj-konvejer-i-ehkspluataciya-pt-application-inspector/

• Опенсорс с методикой внедрения и примерами скриптов и шаблонов для GitLab CI: github.com/devopshq/dohq-ai-best-practices

Итоги

Итак, мы  рассказали о нашем первом опыте эксплуатации PT Application Inspector и его внедрении в реальный сборочный процесс. Также мы предложили максимально упрощённую архитектуру и методику внедрения PT AI в CI.

Основные рекомендации на данный момент заключаются в том, чтобы "обернуть" клиента AISA в докер-образ, разместить серверную часть Application Inspector Enterprise на отдельной виртуальной машине и добавить в свой сборочный проект шаблоны для запуска сканирования кода через AISA-клиент. Подключать проекты на сканирование при этом возможно в пару строчек кода. Один-два CI-инженера средней квалификации смогут разобраться, что к чему в нашей методике, и повторить аналогичный процесс в своей компании. Демо, показанное на вебинаре, это то, как работает PT AI на данный момент в CI-конвейере у нас в компании.

Конечно, всё рассказать в одной статье невозможно. В следующих статьях покажем, как именно и какие результаты сканирования и найденные уязвимости блокируют выпуск наших релизов, а также как разработчики работают с PT Application Inspector.

Авторы статьи, разработчики архитектуры, методики и скриптов интеграции для PT AI:

• Тимур Гильмуллин — заместитель руководителя отдела технологий и процессов разработки в Positive Technologies,

• Дмитрий Рагулин — CI-инженер отдела технологий и процессов разработки.

Обновление. Читайте продолжение истории о том, как у программистов изменился процесс разработки и выпуска релиза, в статье по ссылке.