Привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки 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-проекты, создав так называемую релизную схему сборок с продвижениями, которая сейчас используется для всех продуктов компании.
Спойлер
Производственный конвейер в компании за многие годы усложнился и сейчас состоит из десятков отдельных технологических этапов. Если упростить и обобщить текущую релизную схему, то она включает в себя:
кроссплатформенную сборку продукта;
деплой на тестовые стенды;
выполнение функциональных и иных тестов;
продвижение протестированных сборок в релизные репозитории на Artifactory;
публикацию релизных сборок на сервере обновлений GUS;
доставку сборок и обновлений при помощи FUS-серверов;
запуск инсталляции или обновления продукта на инфраструктуре заказчиков.
Перед нами встала задача: внедрить в уже имеющиеся и сложившиеся сборочные процессы новый этап сканирования кода при помощи 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.
Плюсы и минусы
Плюсы архитектуры:
Минимальные трудозатраты инженеров группы инфраструктуры на развёртывание, эксплуатацию и обновление сервера AIE, в отличие от двух других вариантов.
Требуется настройка мониторинга только для сервера AIE и сканирующих агентов, то есть небольшого количества ВМ.
Наличие API: команды для передачи кода на сканирование унифицированы через легковесный клиент AISA и в будущем не придётся перенастраивать сотни сборочных конфигураций в случае изменения контрактов в новых версиях AIE-сервера.
По аналогичному принципу (передача кода на анализ во внешние сервисы) работают все облачные сканеры кода, например, Codacy и SonarQube. Хотя есть и GitLab, который использует интегрированное серверное решение для своего Code Quality сервиса.
В предлагаемой архитектуре можно отделить анализ кодовой базы от сборочного процесса.
Минусы архитектуры:
Чуть более сложное внедрение анализатора кода в сборочный процесс, за счёт дополнительных шагов настройки сборки и проекта сканирования. Здесь требуется разработка скриптов интеграции с CI-системами и шаблонов для запуска сканирования. Это немного сложнее, чем в случае, когда AIE-сервер и агент сканирования расположены на самом билд-агенте.
Потенциально может возникнуть больше проблем со сборками, за счёт добавления нового внешнего сервиса в сборочный конвейер.
Возможно значительное увеличение ожидания сборок в очереди, пока идёт сканирование на AIE-сервере.
Трудно спрогнозировать требования по железу для масштабирования и обеспечения сканирований для десятков тысяч сборок в день.
На момент внедрения PT AI в наш сборочный конвейер, плюсы указанной архитектуры значительно перевесили минусы.
Обновлённый сборочный процесс с использованием PT AI
Мы определились, что будем запускать сканирование кода до выполнения шага компиляции компонент на этапе сборки. Сервер AIE в нашей инфраструктуре будет размещён на отдельной виртуальной машине, а запуском сканирования и передачей кода на анализ будет заниматься консольный клиент AISA, "обёрнутый" в докер.
В качестве основной CI-системы мы используем GitLab CI, а все технологические шаги и этапы реализуем в виде шаблонов в файлах .gitlab-ci.yml . На схеме представлен обновлённый CI-процесс, который мы тиражируем внутри компании, с учётом новых шагов сканирования.
Детализация шагов сборочного процесса с помощью PT AI
Сборка, запущенная на билд-агенте, запрашивает исходный код из GitLab.
Исходный код скачивается на билд-агент в рабочую директорию сборки.
Запускается так называемый build-on-server сборочный скрипт (bash или batch), который реализует логику разработчиков и все шаги сборки компоненты. Это точка входа для отделения логики сборки от её исполнения в CI-конвейере. Разработчики пишут build-on-server скрипт, так как лучше знают детали компиляции своего продукта, а CI-инженеры вызывают его в шагах сборки в CI-системе.
Отдельным шагом запускается докер и легковесный консольный клиент AISA, которому передаются все необходимые параметры для выполнения сканирования: имя проекта на сервере AIE, язык программирования, путь до локального каталога на сборочном сервере с исходным кодом и, при необходимости, некоторые другие параметры.
AISA-клиент стартует и выполняется физическое копирование на сервер AIE исходного кода собираемой компоненты. Как уже отмечалось — это временное решение.
Сейчас этого шага нет, но уже в ближайшем будущем на шаге 5, вместо физического копирования исходников со сборочного агента, AISA будет передавать на сервер AIE некий ключ (имя проекта и ветка, либо конкретный hash коммита), однозначно идентифицирующий проверяемый код. Либо сам сервер AIE будет интегрирован с GitLab-сервером и будет знать, где лежит исходный код проекта и все его ветки. Это позволит избежать лишних манипуляций с копированием кода.
AIE-сервер получает код и запускается сканирующий агент для его анализа. Здесь есть варианты: либо дождаться окончания сканирования и сразу получить отчёт в сборке, либо не ждать результаты, продолжить выполнение остальных сборочных шагов, а результаты посмотреть позднее на сервере через веб-приложение.
В любом случае нужно дождаться кодов возврата (exit code) от сервера. Если передача исходного кода на сервер или само сканирование завершились с ошибкой, он вернёт ненулевой код. Далее логика сборки зависит от реализации CI-инженером и требований к процессу от разработчиков: если очень важно получить результаты анализа кода, например, для релизных сборок, то в случае любых ошибок можно сразу фейлить сборку. Для нерелизных сборок любые ошибки от AIE-сервера можно игнорировать и продолжать обычную сборку компоненты.
Если все предыдущие шаги окончились успешно, то запускается стандартное модульное юнит-тестирование и продолжают выполняться оставшиеся шаги, заложенные в логику сборки.
Если все шаги сборки окончились успехом, то скомпилированный бинарь выгружается на Artifactory.
Артефакт публикуется на Artifactory в соответствующем продуктовом snapshot-репозитории и сохраняется для последующего деплоя на тестовый стенд, выполнения тестирования и остальных типовых этапов схемы сборки с продвижениями, рассмотренной ранее.
Основные этапы методики внедрения PT AI в CI
Для упрощения работы CI-инженеров мы подготовили небольшой список рекомендаций по внедрению и технической эксплуатации серверной, клиентской и CI частей PT AI. Эти рекомендации можно представить в виде шагов простой методики: подготавливаем серверную часть, организуем релизный цикл для клиента AISA, подготавливаем проект сканирования для AIE-сервера и начинаем работать со сканами в CI-системах.
Основные этапы методики внедрения PT AI в 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.
Таблица с рекомендуемыми характеристиками сервера
Рекомендуемые на данный момент характеристики сервера и агента представлены в таблице (они могут измениться для новых версий и лучше смотреть официальную документацию).
PT AI Enterprise Server | Процессор Intel Core i7 с частотой 3,2 ГГц или аналоги |
От 8 ГБ оперативной памяти | |
От 200 ГБ на жестком диске | |
Сетевой адаптер от 10 Мбит/с | |
64-разрядная версия Windows Server 2012 R2 и выше | |
Средство автоматизации Windows PowerShell версии 5.0 и выше | |
PT AI Enterprise Agent | Процессор Intel Core i7 с частотой 3,2 ГГц или аналоги |
От 8 ГБ оперативной памяти | |
Сетевой адаптер от 10 Мбит/с | |
Браузер: Microsoft Edge, Mozilla Firefox 46 и выше, Google Chrome 50 и выше |
Релизный 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, а также он может создавать и настраивать на сервере проекты сканирования и получать по ним отчёты. Кроме клиента мы добавляем в докер различные вспомогательные утилиты .
Скриншот с примером запуска AISA-клиента в консоли
Примеры аргументов
В таблице приведены примеры аргументов: ключей и значений для запуска AISA (они также могут измениться в новых версиях и лучше смотреть официальную документацию).
Параметр запуска | Описание | Обязательный параметр? |
--project-name | Название проекта (регистронезависимо), который надо просканировать. Проект должен быть создан на сервере AIE на момент запуска сканирования. Пример значения: DevOpsSandbox | Да, при отсутствии ключа --project-settings-file |
--project-settings-file | Путь к файлу с настройками проекта Пример: Test.aiproj | Да, при отсутствии ключа --project-name |
--policies-path | Путь к файлу с описанием политик. Пример значения: ./policy.json | Нет |
--scan-target | Путь к каталогу или файлу приложения для сканирования. Пример значения: source/folder | Да |
--reports-folder | Путь к каталогу, куда будут сохранены файлы отчетов. Пример значения: .ptai | Нет |
--reports | Типы отчетов, создаваемых по окончании сканирования. Может принимать одно или несколько значений через запятую: HTML, PDF, JSON, WAF Пример значения: "HTML,JSON" | Нет |
--no-wait | Отключает ожидание результатов сканирования, значительно сокращает время работы | Нет |
--scan-off | Отключает сканирование на AIE сервере, используется для создания проекта (в паре с аргументом --project-settings-file) | Нет |
Внедрение 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-инженер отдела технологий и процессов разработки.
