DevSecOps на отечественном стеке: GitFlic CI + PT Application Inspector + Harbor

Раньше на вопрос «как у вас устроен DevSecOps?» большинство заказчиков отвечали «GitLab Ultimate с Security Dashboard». Это работало, пока GitLab Ultimate был доступен. Сейчас ситуация другая, и несколько проектов у нас перешли к варианту, который ещё полгода назад казался экзотикой: GitFlic как SCM и CI, PT Application Inspector для SAST, Harbor для хранения образов. Записали схему и честное ощущение от покрытия.

Почему именно этот набор

Выбор компонентов не был произвольным - у заказчика требование по реестру отечественного ПО (приказ Минцифры, ФСТЭК), плюс инфраструктура на КИИ, где использование зарубежных SaaS-инструментов в цепочке разработки формально не проходит через модель угроз.

GitFlic - отечественный git-хостинг с встроенным CI-раннером. До масштабного замещения конкурентов в РФ был в тени, сейчас активно развивается. YAML-синтаксис пайплайнов похож на GitLab CI, но не идентичен - это важно: прямой миграции .gitlab-ci.yml нет, переписывать руками.

PT Application Inspector (он же Swordfish в части SAST-движка) - продукт Positive Technologies для статического анализа кода. Умеет Java, C#, PHP, Python, JavaScript, Go. Есть режим incremental-анализа и интеграция через CLI/API. Включён в реестр, есть сертификат ФСТЭК.

Harbor - технически не отечественный (CNCF-проект), но в ряде проектов его принимают как open source без ограничений. Для реестра с RBAC, vulnerability scanning через Trivy и политиками pull/push это разумный выбор даже без импортозаместительного мандата.

Схема конвейера

Developer push
  -> GitFlic SCM (code review, MR)
  -> GitFlic CI runner
       |
       +--> PT Application Inspector (SAST)
       |        -> результаты в артефакты пайплайна
       |        -> при HIGH/CRITICAL - fail pipeline
       |
       +--> Build Docker image
       |
       +--> Trivy scan (через Harbor API или локально)
       |        -> CVE в базовом образе
       |
       +--> Push to Harbor
                -> политика: только образы без CRITICAL CVE

Запуск SAST происходит до сборки образа - это принципиально: не тащить статические дефекты дальше по конвейеру. PT AI в режиме --fail-policy возвращает ненулевой exit code при находках выше порога, и GitFlic CI штатно ловит это как сбой шага.

Что реально проверяется

Честный ответ: не всё, что хотелось бы.

Покрыто хорошо:

• SQL-инъекции, XSS, SSRF - это PT AI находит стабильно, даже в запутанном коде с несколькими уровнями абстракции. На нашем пилоте (Java-приложение, ~80k строк) ложноположительных было около 15% - приемлемо для первого прогона, потом можно настроить whitelist.
• Hardcoded credentials - ключи, пароли, токены в коде. Движок цепляет не только очевидные password = "...", но и паттерны в конфигурационных файлах внутри репозитория.
• Небезопасные криптопримитивы - MD5, DES, устаревшие TLS-конфигурации в коде.
• CVE в зависимостях - через Trivy при сборке образа. Не часть PT AI, но закрывает SCA-уровень.

Покрыто частично или не покрыто:

• Secrets в git-истории - PT AI анализирует текущий HEAD, не историю коммитов. Для ретроспективного поиска нужен отдельный инструмент типа truffleHog или gitleaks - в пайплайн не интегрировали, пока сделали разовый прогон вручную.
• DAST - динамический анализ в этой схеме отсутствует. Без него SQL-инъекции в параметрах, которые не видны статически, остаются в слепой зоне.
• IaC-анализ - Terraform, Ansible, Helm-чарты PT AI не анализирует. Чеклист проверки инфраструктурного кода пока ручной.

Боль интеграции

Самым трудоёмким оказалась не архитектура, а детали:

GitFlic CI и артефакты. Механизм публикации артефактов пайплайна (отчёты PT AI в формате JSON/HTML) устроен иначе, чем в GitLab. Нет встроенного рендеринга Security Reports в интерфейсе MR - отчёт надо скачивать вручную или парсить CI-скриптом и публиковать как комментарий. Реализовали через bash-скрипт, который выгружает summary в тело MR-комментария через GitFlic API.

PT AI CLI и прокси. На изолированном стенде PT AI ходит за обновлениями баз уязвимостей - нужен либо выход наружу, либо offline-обновление через утилиту управления базами. Offline-вариант задокументирован, но менее очевиден при первоначальной настройке.

Harbor и политики. Настройка Content Trust (нотариат образов) с GitFlic CI потребовала явной интеграции: раннер должен подписывать образ при push. Пока работаем без подписи - в бэклоге.

Где стоим

Пайплайн работает на двух проектах, SAST прогоняется на каждый MR. Время одного прогона PT AI на нашем Java-проекте - около 12 минут, что вписывается в приемлемые рамки для ревью. Для критичных находок пайплайн блокирует слияние - работает как ожидается.

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