Как выбрать SAST-анализатор: критерии и чек-лист

Выбирать SAST-анализатор нужно не по числу заявленных языков и правил, а по результату на вашем собственном коде: сколько реальных уязвимостей он находит, сколько шума создаёт и насколько легко встраивается в ваш конвейер сборки. Короткий путь: составьте список требований из шести-семи критериев ниже, отберите 2–3 кандидата и сравните их на одном и том же наборе репозиториев.

Что должен делать SAST и чего он не сделает

Статический анализ (SAST) изучает исходный или бинарный код без запуска приложения и ищет пути, по которым недоверенные данные попадают в опасные функции: SQL-инъекции, XSS, обход каталогов, небезопасную криптографию, захардкоженные секреты. Он работает рано, в IDE или на pull request, и показывает конкретную строку. Руководство OWASP DevSecOps Guideline советует запускать SAST на pull request и сочетать его с SCA для зависимостей, а инструмент подбирать под используемый стек.

Чего SAST не делает: не видит ошибок конфигурации окружения, не проверяет уязвимости в сторонних библиотеках (для этого нужен SCA) и не заменяет динамическое тестирование. Подробнее о границах классов инструментов: SAST, DAST, SCA и MAST: в чём разница.

Критерии выбора SAST-анализатора

1. Языки и фреймворки именно вашего стека

Цифра «поддерживает 30+ языков» ничего не говорит о глубине. Часть языков поддерживается на уровне простых шаблонов, часть — с полноценным анализом потоков данных. Даже в документации Semgrep прямо сказано, что зрелость поддержки различается от языка к языку. Составьте список языков, фреймворков и версий, которые реально используются в продуктивных системах, и проверяйте анализатор на них, а не на демонстрационных проектах вендора. Отдельно уточните: нужен ли анализ мобильного кода, SQL-диалектов, скриптов 1С, legacy-языков банковского ядра.

2. Точность: ложные срабатывания и пропуски

Это главный критерий. Анализатор с большим количеством ложных срабатываний разработчики перестают читать через месяц. Анализатор с пропусками создаёт ложное чувство безопасности. Глубина анализа влияет на оба показателя: в документации Semgrep отмечено, что анализ между файлами даёт меньше ложных и больше истинных срабатываний, но занимает больше времени, а редакция Community анализирует лишь в пределах функции или файла. Задайте вендору вопросы: есть ли межпроцедурный и межфайловый анализ, подтверждает ли инструмент уязвимости (например, тестовым запросом), можно ли помечать и подавлять срабатывания с комментарием.

3. Интеграция в процесс разработки

Проверьте, что анализатор работает там, где работают ваши команды:

Системы контроля версий и CI/CD: GitLab, GitHub, Bitbucket, Jenkins, TeamCity; наличие CLI и REST API.
Трекеры задач: передача находок в Jira или аналог без ручного копирования.
Режим pull request: инкрементальное сканирование только изменённого кода, иначе проверка будет занимать часы.
IDE: плагины полезны, но вторичны по сравнению с pull request.

О практике встраивания читайте в материале «DevSecOps: с чего начать».

4. Модель развёртывания и работа с данными

Для банков, телекома и госсектора в Центральной Азии исходный код часто нельзя передавать во внешнее облако. Выясните, есть ли полноценная on-premise-установка (а не урезанная версия), работает ли она в закрытом контуре без выхода в интернет и как поставляются обновления правил. У ряда международных платформ основной продукт облачный, а локальный вариант предлагается отдельно или ограниченно: например, на странице Checkmarx One облачная платформа показана как основная, а on-premise SAST упоминается отдельно. Не предполагайте, а запрашивайте письменное подтверждение.

5. Тип анализа: исходный код, бинарный код, композитный анализ

Если у вас много кода подрядчиков или legacy без исходников, пригодится бинарный анализ. Если нужен весь AppSec-контур, оцените, есть ли у платформы SCA и DAST в том же интерфейсе, — это упрощает отчётность и лицензирование, хотя не всегда лучшее решение по каждому классу. Платформы полного цикла вроде DerScanner объединяют SAST, SCA, DAST, мобильный и бинарный анализ.

6. Отчётность и соответствие требованиям

Спросите, есть ли отчёты по OWASP Top 10, PCI DSS и другим стандартам, которые проверяют ваши аудиторы, и можно ли экспортировать результаты в SARIF или иной машиночитаемый формат. У российских решений на рынке встречается сертификация ФСТЭК и включение в реестр отечественного ПО; для компаний Казахстана и Узбекистана эти статусы сами по себе не обязательны, но влияют на закупочные требования, если вы работаете с российскими партнёрами.

7. Расширяемость: собственные правила

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

8. Стоимость владения

Модель лицензирования (по разработчикам, по строкам кода, по проектам, по серверам сканирования) по-разному ведёт себя при росте. Публичные цены есть не у всех вендоров, у многих корпоративных решений стоимость определяется по запросу. Считайте не только лицензию, но и инфраструктуру, трудозатраты на разбор находок и поддержку. Подробнее — в материале open-source или коммерческие AppSec-инструменты.

Чек-лист для сравнения кандидатов

Языки: все ваши языки и версии проверены на реальном коде.
Точность: на эталонной выборке посчитана доля подтверждённых уязвимостей среди находок.
Пропуски: на репозитории с известными уязвимостями (из прошлых пентестов) проверено, что найдены известные дефекты.
CI/CD: сканирование pull request укладывается в допустимое время.
Развёртывание: on-premise или облако подтверждено документально.
Отчёты: формат подходит для аудита и для разработчиков.
Правила: можно писать собственные.
Поддержка: язык, часовой пояс и срок реакции технической поддержки устраивают.
Стоимость: получено коммерческое предложение с расчётом на 3 года.

Как проверить анализатор на своём коде

Практика показывает, что презентации вендоров и обзоры в интернете не заменяют пилот. Алгоритм простой:

Выберите 3–5 репозиториев: разные языки, разные команды, один проект с известными уязвимостями.
Просканируйте их всеми кандидатами с настройками по умолчанию, затем с настройкой.
Разберите случайную выборку находок вместе с разработчиками и отметьте истинные и ложные.
Измерьте время сканирования полного репозитория и pull request.
Оцените усилия на установку, настройку и обновление.

Как организовать такую проверку по неделям, мы описали в статье «Как провести пилот SAST и SCA за 30 дней». Если вы сравниваете конкретные продукты, посмотрите сравнение SAST-решений.

Типичные ошибки при выборе

Выбор по числу правил или языков. Важно не количество, а качество на вашем стеке.
Тест на демо-проекте вендора. Он заведомо подобран под сильные стороны продукта.
Игнорирование разработчиков. Если они не участвуют в выборе, инструмент будут обходить.
Включение всех правил сразу. Начните с критичных классов уязвимостей и расширяйте набор постепенно.
Отсутствие владельца процесса. Кто-то должен разбирать находки и назначать исправления, иначе сканер превращается в источник шума.

Роли в выборе: кто за что отвечает

Выбор SAST — командная задача, и у каждой роли свой набор вопросов. Специалист по ИБ отвечает за покрытие классов уязвимостей, отчётность и соответствие требованиям. Руководитель разработки смотрит на скорость сканирования, удобство для разработчиков и влияние на сроки релизов. DevOps-инженер проверяет интеграцию с конвейером, требования к серверам и порядок обновления. Финансовый директор интересуется моделью лицензирования и итоговой стоимостью. Если кого-то из этих людей нет за столом, проблемы всплывут уже после покупки: разработчики откажутся работать с инструментом, а инфраструктура не потянет нагрузку.

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

Частые вопросы

Можно ли обойтись бесплатным SAST?

Для небольших команд и простых проверок открытые инструменты вроде Semgrep Community Edition часто достаточны. Но у них есть ограничения: Community Edition анализирует код только в пределах функции или файла, что может давать пропуски. Для крупных кодовых баз и требований аудита обычно нужны коммерческие решения или комбинация подходов.

SAST или DAST: что выбрать первым?

Они закрывают разные задачи. SAST работает с кодом на ранних этапах, DAST проверяет работающее приложение снаружи. Если приходится выбирать одно с чего начать, для команд с собственной разработкой чаще начинают со SCA и SAST, а DAST добавляют для внешнего периметра.

Сколько времени нужно на выбор?

Реалистично уложиться в 4–6 недель: неделя на требования, 30 дней на пилот двух-трёх кандидатов и время на согласование коммерческих условий.

Нужен ли on-premise SAST?

Если исходный код нельзя передавать за пределы вашего контура по требованиям внутренней политики или регулятора, то да. Уточняйте у вендора, что локальная версия функционально равна облачной.

Хотите сравнить SAST-анализаторы на своём коде? Эксперты AST Cyber Lab помогут составить требования, организовать пилот DerScanner и оценить результаты вместе с вашими разработчиками.

Обсудить пилот SAST

Источники

Решения по теме

DerScanner →