Отечественные SAST в CI-пайплайне: пилот на GitFlic и сравнение с зарубежными аналогами

Тема отечественных инструментов статического анализа кода поднималась у нас в команде несколько раз за год - всегда в режиме «надо бы проверить, как оно сейчас». В этот раз не отложили: один из клиентов переводил разработку на GitFlic и параллельно хотел встроить SAST в pipeline. Вопрос «брать отечественное или протащить Semgrep через VPN-костыли» стал вполне конкретным.

Что и зачем пилотировали

Клиент - небольшая команда разработки в организации под требованиями КИИ, Java-монолит и несколько Python-сервисов, репозитории уже переехали на GitFlic. Из зарубежных инструментов исторически использовали SonarQube Community Edition и иногда - Semgrep OSS. Задача: найти отечественный SAST, который хотя бы не хуже по ключевым параметрам, а в идеале - нативно дружит с GitFlic-пайплайнами и не требует проксировать трафик через сторонние узлы.

Взяли в пилот два российских инструмента - Swordfish Security CodeScoring и Solar appScreener. Оба присутствуют в реестре российского ПО, оба декларируют поддержку CI/CD интеграции. Сравнивали с SonarQube Community в качестве базовой линии.

Пилот длился около трёх недель. Анализировали один и тот же кодовой срез - Java-модуль с историческим долгом: несколько известных находок из прошлых аудитов, намеренно оставленные для проверки, плюс набор тест-кейсов на типовые уязвимости (SQL injection, XXE, небезопасная десериализация, жёстко зашитые credentials).

Интеграция с GitFlic

Это оказался самый показательный блок. GitFlic поддерживает CI через собственный runner и webhook-механизм, совместимый с GitLab CI по синтаксису на уровне базовых конструкций. На практике это значит: yaml-пайплайн с script: работает, но часть advanced-фич GitLab CI (кеширование артефактов, environment-переменные из protected branches) работает иначе или не поддерживается совсем.

CodeScoring интегрировался через Docker-образ с CLI. Написали простой stage в .gitflic-ci.yml, запускающий анализ и выгружающий отчёт в артефакты. Декоративно - работает. Но интеграция с pull request flow, то есть постановка inline-комментариев прямо на строки кода в diff, не завелась из коробки: CodeScoring умеет делать это для GitLab, для GitHub, для Bitbucket - для GitFlic на момент пилота специфического плагина нет. Результат получали как файл с SARIF-отчётом, который открывали отдельно. Для команды, привыкшей к inline-замечаниям в MR, это шаг назад.

Solar appScreener поставляется как on-premise платформа с веб-интерфейсом. CI-интеграция - через API: запускаешь сканирование POST-запросом, ждёшь, забираешь результаты. Скрипт получился длиннее, чем хотелось бы, но заработал. Inline-комментарии в GitFlic тоже не поддерживаются нативно - опять SARIF на выходе. Зато у appScreener есть собственный портал для разработчиков с хорошей навигацией по уязвимостям - если использовать его как основной интерфейс, недостаток GitFlic-интеграции менее болезненен.

SonarQube в режиме сравнения настроили так же - через runner, без плагина для GitFlic. Результат аналогичный: работает, но inline-комментарии в MR тоже не из коробки. Так что здесь отечественные инструменты не проигрывают зарубежным в конкретной связке с GitFlic - все трое оказались примерно в одной лодке.

Покрытие правил и false positive rate

Тут картина интереснее.

SQL injection, XXE, жёстко зашитые credentials - все три инструмента нашли без настройки. Расхождений почти нет.

Небезопасная десериализация Java - CodeScoring и SonarQube нашли все подготовленные кейсы, appScreener пропустил один из четырёх. Воспроизводимо.

False positives - и вот здесь разрыв ощутимый. На том же кодовом срезе SonarQube выдал по Java-модулю вполне терпимый уровень шума. CodeScoring - заметно больше, значительная часть из которых - ложные срабатывания на паттерны, которые в контексте приложения безопасны. AppScreener - где-то посередине, но с другим характером шума: больше срабатываний на конфигурационные файлы, меньше - на логику.

Отдельно проверили Python-сервисы. CodeScoring справился нормально - покрытие сопоставимо с Semgrep OSS на стандартных правилах. AppScreener с Python работает заметно хуже: часть детекторов выглядит как портированные без адаптации под Python-специфику, и это чувствуется.

Практический итог

Мы не пришли к выводу «берите X, он лучший» - ситуация пока не такая однозначная. Но несколько наблюдений оформились чётко.

• Функциональная зрелость есть, но неравномерная. CodeScoring для Java вполне конкурентен по покрытию. Для Python - пока слабее зарубежных аналогов. AppScreener силён в платформенной части (управление результатами, трекинг по релизам), но в глубине анализа Python и в GitFlic-интеграции пока уступает.

• GitFlic + SAST - это DIY. Ни один из инструментов не даёт нативного inline PR-review в GitFlic. Если для команды это критично - придётся либо строить обёртку самостоятельно, либо смириться с работой через отдельный портал.

• False positive rate - главная боль. Высокий шум убивает adoption: разработчики перестают смотреть на предупреждения. Это не специфика отечественных инструментов - SonarQube тоже не идеален, - но при переходе нужно закладывать время на настройку профилей правил.

Клиент решил остановиться на CodeScoring для Java-части и на время оставить Semgrep для Python, пока ситуация с поддержкой языка у отечественных инструментов не прояснится. Для аудита безопасности такой гибридный подход нас устраивает: инструмент должен работать, а не быть отечественным ради галочки. Хотя, если честно, по Java-части разрыв сократился достаточно, чтобы аргумент «российское хуже» уже не работал автоматически.