Всем привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки 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 в этом процессе.
DevSecOps-конвейер в Positive Technologies: безопасный цикличный процесс разработки, сборки, развертывания, тестирования, продвижения, публикации, установки обновлений, сбора телеметрии и мониторингаОбщие 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-конвейере
Сканер 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.
Пример описания правил Security Gates в файле aisa-codequality.settings.yamlСами правила описываются в обычном yaml-файле, состоящем из двух разделов:
-
threats mapping отвечает за маппинг и соответствие терминологии критичности проблем кода самого GitLab (имена ключей) и терминологии критичности уязвимостей PT Application Inspector (значения ключей). Кроме того, для удобства работы в этом разделе можно сгруппировать уязвимости по типу. Например, сказать, чтобы GitLab сгруппировал уязвимости уровней Potential, Low, Medium от сканера и отображал их в группе проблем Info.
-
security gates в этой секции задается количество уязвимостей для каждой конкретной группы критичности. Если сканер найдет в коде указанное число или больше уязвимостей, то мердж-реквест или сборка будут заблокированы. Если задать значение ноль, проверка количества для соответствующей группы выполняться не будет. Если нули заданы для всех групп, то сканирование фактически будет вестись в режиме информирования.
Правила Security Gates в обоих разделах должны быть согласованы со специалистами по информационной безопасности в компании. На время разработки фич в отдельных ветках эти правила могут быть смягчены, чтобы не мешать быстрой разработке. Но в момент влития кода в релизные ветки обязательно должны использоваться максимально жесткие правила.
Пример портянки сообщений от SonarQube в треде мердж-реквеста GitLabВ качестве основы для интеграции сканера кода мы решили взять вариант интеграции известного продукта SonarQube через штатный механизм GitLab codequality. Мы посмотрели, как он внедряет свои сообщения в мердж-реквест, и спросили наших разработчиков, насколько им это удобно. Оказалось, что большинству такая портянка сообщений в треде мешает, особенно когда приходится работать с legacy-кодом, для которого замечаний бывает очень много. Кроме того, открывается страничка с сотнями сообщений небыстро.
Поэтому, когда мы работали над внедрением нашего сканера в сборочные процессы, то решили сразу позаботиться об удобстве программистов и сделать более удобное отображение рекомендаций по безопасности, в одном треде мердж-реквеста. Этот тред обновляется автоматически с помощью специального бота, написанного нашими CI-инженерами для интеграции AISA с GitLab CI.
Security Gates: проверки
Пример треда мердж-реквеста в GitLab, не заблокированного ботом, так как правила Security Gates выполняютсяЕсли уязвимости найдены, но проходят условия Security Gates, то в сборке специальный шаг Code Quality Status выставляется в значение 0 (Passed). В этом случае мердж-реквест не будет заблокирован, а в треде на GitLab программист увидит комментарий от бота с перечислением найденных (некритичных для данного набора правил) уязвимостей. Прямо в треде он сможет посмотреть, что это за уязвимости, либо перейти по ссылкам к полному HTML-отчету или в сборку на GitLab CI или TeamCity, если сборка была инициирована там.
Пример треда мердж-реквеста в GitLab, заблокированного ботом, так как нарушено правило Security Gates: major-проблем (Medium-уязвимостей от сканера) не более двухВо втором случае, то есть если уязвимости найдены и не проходят условия Security Gates, значение Code Quality Status выставляется в 1 (Failed) и мердж-реквест блокируется путем добавления ключевого слова Draft в его заголовок.
В комментариях от бота, кроме всей прочей информации, указывается причина блокировки, то есть текущий набор правил Security Gates для ветки, где идет сборка.
При каждом сканировании бот обновляет один и тот же тред на страничке мердж-реквеста: все уязвимости удобно группируются и отображаются в одном месте.
Пример интеграции отчета от сканера в сборки на TeamCityВ сборки на 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 у наших продуктов может быть одновременно несколько поддерживаемых релизов, поэтому используется несколько релизных веток.
При запуске сборки или мердж-реквеста из конкретной ветки вызывается тот шаблон сканирования, который лежит в этой ветке. Приведу примеры режимов работы сканера, которые можно использовать при мердж-реквестах из различного типа веток.
Схема классического git-flow и рекомендуемые шаблоны для различных ветокМы рекомендуем:
-
В 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)
Если вас интересует тема кибербезопасности, следите за нашими вебинарами и новыми статьями в блоге компании. А на этом пока все. Ждем ваших вопросов в комментариях :)
Автор статьи: Тимур Гильмуллин заместитель руководителя отдела технологий и процессов разработки в 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 и помощь с его внедрением в компании, а также всем разработчикам сканера за прекрасный продукт :)