SAST в 2025: как выбрать SonarQube, Semgrep или Checkmarx

Что болит у команд при внедрении SAST

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

После первого запуска многие команды начинают игнорировать алерты. Не потому что «всем все равно», а потому что полезный сигнал быстро тонет в шуме.

Чаще всего шум появляется из-за понятных причин: много ложных срабатываний и кейсов, где без контекста непонятно, есть ли риск; отчеты приходят слишком поздно (после мержа или релиза); нет ясных правил приоритета (что критично, а что можно отложить); не назначены владельцы процесса (кто делает triage, кто заводит задачи, кто утверждает исключения); инструмент первым делом «взрывается» на легаси и приносит тысячи проблем в первый день.

От quality gate обычно ждут две вещи одновременно: меньше риска и меньше шума. Нужен понятный «стоп» на реально опасные изменения (например, новая критическая уязвимость в платежном коде или в сервисе с персональными данными), но без остановки разработки из-за старых хвостов.

Здесь важно разделять выбор инструмента и настройку процесса. Инструмент отвечает за покрытие языков, точность правил и удобство интеграций. Процесс - за то, как команда живет с результатами: baseline для старых проблем, сроки исправления по критичности, понятные исключения и принцип «gate смотрит на новый код». Без этого даже хороший SAST превращается в фоновый шум, который в итоге отключают.

SonarQube, Semgrep, Checkmarx: что именно сравнивать

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

SonarQube часто воспринимают как «качество кода плюс безопасность»: много правил про баги, поддерживаемость и стиль, а безопасность идет рядом. Semgrep ближе к идее «быстро и гибко»: правила можно писать и менять как код, что удобно командам, которые хотят контролировать логику проверок. Checkmarx обычно выбирают там, где нужен более «корпоративный» контур: широкий набор проверок, управление политиками, отчеты и процесс вокруг уязвимостей.

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

Для сравнения заранее зафиксируйте критерии. Обычно это:

• охват (языки и фреймворки именно вашего стека),
• точность (полезные алерты против «шума»),
• скорость (сколько минут добавляет проверка в CI),
• удобство для разработчика (IDE, комментарии в PR, понятные подсказки по фиксу),
• управляемость (роли, политики, аудит, отчеты для безопасности).

И не забывайте про скрытые затраты. На практике время уходит не на «покупку», а на настройку правил, интеграции с CI и трекером задач, поддержку и обновления (особенно on-prem), обучение команды разбору находок и договоренности о том, кто и как принимает риск.

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

Выбор по языкам и стекам: как не промахнуться

Начинайте не с названий, а с того, что реально живет в репозиториях: языки и версии, фреймворки, сборка, тесты, типичные паттерны (ORM, шаблонизаторы, API-шлюзы). Частая ошибка - взять «топовый» продукт и потом обнаружить, что он отлично работает на одном сервисе и почти бесполезен для половины кода.

Если у вас монорепо и несколько команд, важна не только поддержка языка, но и поведение на большом дереве с разными требованиями. Команде фронтенда обычно нужен быстрый фидбек в pull request, а для критичных сервисов платформы важнее строгие проверки и политика. До пилота проверьте базовые возможности: умеет ли инструмент сканировать измененные части, задавать разные правила для разных папок или проектов, выдавать результат по компонентам (а не один общий отчет) и работать в вашем CI без постоянных ручных обходов.

Учитывайте специфику продукта. Для backend чаще важны инъекции, небезопасная сериализация, ошибки авторизации и секреты. Для frontend - XSS, опасная работа с HTML и зависимости. Для мобильных - хранение токенов, криптография, сетевые настройки и сборочные профили. Один инструмент может быть сильным в Java и слабым в Swift (или наоборот).

Поддержку лучше проверять не по маркетинговым таблицам, а маленьким тестом на вашем коде. Возьмите один реальный сервис или мини-проект и сделайте короткий пилот: 2-3 уязвимости, которые вы хотите ловить; 1-2 места, где обычно много ложных срабатываний; прогон на ветке и на pull request; затем оценка - нашли ли нужное и сколько времени ушло на разбор.

Отдельно подумайте про IaC и конфиги (Terraform, Kubernetes YAML, CI-скрипты). Это часто дает быстрые находки, но на старте добавляет шум. Практичный компромисс - включать IaC после того, как вы добились приемлемого качества алертов по основным языкам, и начать с самых критичных правил (открытые порты, публичные бакеты, секреты в переменных).

Правила, обновления и исключения: как оценить ценность до покупки

Выигрывает не инструмент, где «больше правил», а тот, где правила закрывают ваши реальные риски и не превращают работу в бесконечный triage. Поэтому относитесь к правилам как к продукту: кто их пишет, как они обновляются и насколько понятны результаты.

Хорошее правило обычно опирается на понятный источник (CWE, OWASP, secure coding гайды или исследования вендора), дает уровень уверенности и показывает примеры. Пример часто важнее формального описания: если алерт не объясняет, что именно опасно и как исправить, разработчик либо игнорирует его, либо чинит «наугад».

Для быстрой проверки набора правил на пилоте достаточно:

• выбрать 10-15 типовых уязвимостей под ваши языки (инъекции, SSRF, небезопасная десериализация, секреты),
• посмотреть, как инструмент объясняет фикс и насколько последователен маппинг на CWE/OWASP,
• оценить «сигнал/шум» на реальном коде,
• проверить, как часто обновляются правила и что происходит с порогами после обновлений.

Кастомные правила нужны не всем. Они полезны, если у вас внутренние фреймворки, свои безопасные обертки или регуляторные требования к паттернам кода. Но почти всегда это нагрузка на 1-2 людей. Если у них не будет времени, правила устареют, а доверие к SAST упадет.

Исключения допустимы, когда риск принят осознанно. Нормальная практика - фиксировать причину и срок пересмотра: «ложное срабатывание из-за санитайзера», «код только для тестов», «плановый рефакторинг в следующем релизе». Лучше, когда исключение привязано к конкретному месту и версии, а не выключает правило «везде».

Качество алертов: как измерять и улучшать

Качество алертов проще измерять не количеством найденных проблем, а тем, сколько из них реально помогает. Ложные срабатывания и пропуски есть у любого инструмента - это рабочая метрика.

Для пилота обычно хватает трех показателей: доля ложных срабатываний (что закрыли как неактуальное), повторяемость алертов по известным паттернам и среднее время до решения по критичным находкам. Пропуски тоже полезно отмечать: если баг нашли на проде или на пен-тесте, зафиксируйте, мог ли SAST найти его и каким правилом.

Чтобы алерты не превращались в шум, нужен простой triage-процесс. Он не должен жить в голове одного человека. Минимальный каркас: разработчик подтверждает контекст, security или архитектор помогает с приоритизацией и исключениями, а дальше есть понятные сроки и статусы (исправлено, ложное с причиной, не применимо с обоснованием, перенесено с датой).

Больше всего времени обычно съедают дубликаты и повторяющиеся паттерны. Хорошо работает «нормализация»: одинаковые алерты объединяются в одну задачу на паттерн, а дальше вы выбираете, что выгоднее - поправить общий шаблон кода, настроить правило или добавить точечное подавление.

Менеджменту не нужны сотни строк деталей. Достаточно 3-5 показателей: сколько критичных открыто, сколько закрыли за период, среднее время реакции, топ причин повторяемости и доля ложных срабатываний (чтобы видеть улучшение качества правил, а не «охоту за ведьмами»).

Пошаговый план пилота: от первого запуска до масштаба

Пилот лучше начинать не с «подключим ко всем репозиториям», а с измеримого эксперимента. Выберите 1-2 проекта, которые отражают ваш стек: один сервис с активной разработкой и один типичный по архитектуре (например, backend плюс немного frontend). Зафиксируйте цель на 2-4 недели: снизить критические уязвимости, улучшить качество кода или сделать релизы предсказуемее.

Подключите анализ в CI так, чтобы он был заметен, но не ломал процесс в первый день. Часто хватает запуска на merge request и ночных прогонов. Дальше команде нужен ритуал: кто смотрит алерты, где они обсуждаются, как принимается решение «исправляем», «подавляем» или «переписываем правило».

После первого прогона сделайте triage 50-100 алертов и отметьте, какие правила дают больше всего шума. Обычно выясняется, что 5-10 правил создают основную долю ложных срабатываний или не подходят под ваши паттерны. В легаси-проектах это особенно заметно: например, правило про «сложность метода» может завалить отчет сотнями замечаний и отвлечь от безопасности.

Чтобы пилот не превратился в спор вкусов, зафиксируйте «правила игры» как результат пилота: какие категории блокируют, какие исключения допустимы и кто их утверждает, можно ли временно помечать accepted risk и на какой срок, какие пороги считаются успехом, и какой шаблон конфигурации пойдет в новые репозитории.

Когда это оформлено, масштабирование становится копированием шаблона, а не новым внедрением. Подключайте команды волнами и начинайте каждую волну с короткого разбора на примерах из их кода.

Quality gate без саботажа: пороги, легаси и исключения

Quality gate чаще ломается не из-за правил, а из-за ожиданий. Если ставить один и тот же порог для нового кода и для легаси, команда начинает «воевать» с инструментом, а не с уязвимостями. Рабочая схема почти всегда одна: новый код контролируем строго, старый долг снижаем по плану.

Для нового кода gate должен быть строгим, но начинать лучше мягко, иначе вы получите блокировку релизов в первый же день. Хороший старт - ловить то, что реально опасно и обычно не вызывает споров: high или critical с понятным путем эксплуатации, блокирующие паттерны вроде SQL-инъекций и обхода авторизации, утечки секретов (ключи, токены) и, если инструмент это поддерживает, критические зависимости с известными CVE.

С легаси подход другой: фиксируете baseline и снижаете долг шагами. Например, раз в спринт закрываете X самых опасных находок или снижаете число high на Y процентов. Тогда gate не превращается в стену.

Исключения должны быть частью процесса, а не лазейкой. Практичный минимум: исключение утверждает не автор кода, а назначенный владелец безопасности или техлид; у каждого исключения есть срок (часто 30-90 дней) и причина; по истечении срока задача возвращается в работу.

Разработчикам проще принять gate через выгоду: меньше ручных проверок, быстрее ревью, меньше сюрпризов на поздних этапах. Типичный компромисс: мердж разрешен, если новый код не добавляет high-алертов и секретов, а легаси живет отдельным бэклогом.

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

Чаще всего проваливается не инструмент, а ожидания. В 2025 почти любая команда может запустить сканер за день, но устойчивый процесс появляется только если заранее договориться: что блокирует релиз, кто разбирает алерты и сколько времени это реально займет.

Повторяются одни и те же ошибки: включить все правила сразу и получить сотни алертов, где важное тонет в мелочах; поставить жесткий gate на весь легаси и остановить релизы; не назначить владельца triage и получить копящиеся дубли; проигнорировать время сканирования и растянуть CI так, что проверку начнут обходить; пытаться заменить SAST обучением (обучение помогает, но без автоматической проверки ошибки возвращаются под дедлайном).

Если нужно простое противоядие, обычно хватает четырех шагов: начать с небольшого набора правил и расширять его по мере доверия; ввести два порога (строго для нового кода и мягко для легаси); назначить ответственного за triage и SLA; замерить время сканирования и решить, что идет в PR, а что уходит в ночные джобы.

Быстрый чеклист перед внедрением

Чтобы выбрать SAST и не испортить CI, полезнее всего сделать несколько быстрых проверок на одном репозитории и одном типичном pipeline.

За один день обычно можно понять главное:

• поддерживаются ли ваши языки и версии на реальной сборке,
• сколько занимает сканирование и как плавает время на тяжелых ветках,
• можно ли настраивать правила на уровне команды или репозитория,
• есть ли понятный triage (ответственные, фиксация false positive),
• можно ли отделить новый код от легаси и блокировать только новые проблемы.

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

Перед тем как включать gate для всех, заранее зафиксируйте ответы на несколько вопросов: какие отчеты и метрики нужны безопасности, разработке и менеджменту; как считается baseline и контролируется «новый код»; как устроены исключения (срок, причина, кто утверждает); как обновления правил влияют на пороги и стабильность.

Пример: как команда дошла до работающего gate за месяц

Команда поддержки продукта держала монорепозиторий с тремя сервисами: Java (основной бэкенд), JavaScript (админка) и Python (пакет для обработки данных). Релизы выходили раз в неделю, и любая задержка била по плану.

На пилоте они включили базовый набор правил в выбранном инструменте и прогнали анализ на весь репозиторий. Результат демотивировал: около 1200 алертов, и по ощущениям большая часть была про стиль и спорные рекомендации, а не про реальный риск. Отчеты быстро перестали читать.

Они сделали это как с шумным мониторингом: сначала снизили шум, потом включили блокировки.

План на 4 недели выглядел так:

• Неделя 1: зафиксировали базовую картину (сколько алертов, где чаще всего, сколько подтверждается). Целью пилота сделали не «закрыть все», а сделать gate полезным.
• Неделя 2: отключили несколько правил, которые давали максимум ложных срабатываний. Для легитимных исключений добавили комментарии с причиной и сроком пересмотра.
• Неделя 3: ввели еженедельный triage на 30-40 минут и договорились о статусах.
• Неделя 4: настроили quality gate так, чтобы он блокировал только новые алерты высокой критичности. Наследованные проблемы ушли в отдельный бэклог с владельцами и датами.

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

Следующие шаги: как перейти от сравнения к рабочему процессу

Самый большой риск после сравнения инструментов - остановиться на выборе и не дойти до привычки. Побеждает тот SAST, который стал частью повседневной разработки и не убивает скорость.

Перед масштабированием помогает короткая подготовка: инвентаризация языков и версий, ключевых репозиториев и CI; назначение владельцев процесса (безопасность - политика и риски, тимлиды - принятие в командах, DevOps - CI и доступы, менеджмент - приоритеты и сроки); минимальный quality gate только для нового кода; понятный процесс исключений; пилот на 2-4 недели на 1-2 репозиториях.

Чтобы пилот был измеримым, выберите 3-5 метрик и снимайте их каждую неделю: доля ложных срабатываний, среднее время до triage, сколько находок исправили, сколько раз сборка была заблокирована и почему.

Хорошо работает «тихий режим» на первой неделе: результаты видны, но сборка не падает. На второй неделе включайте блокировку только по одному классу проблем (например, секреты и SQL-инъекции), а правила про стиль и code smell оставляйте рекомендациями.

Если не хватает рук на настройку CI, раннеров, хранения отчетов и процесса исключений, это уже задача DevSecOps и интеграции. В таких случаях удобнее привлечь системного интегратора. Например, GSE.kz (gse.kz) занимается системной интеграцией и поддержкой 24/7 и может помочь выстроить внедрение и правила quality gate так, чтобы они снижали риск, а не превращались в повод для конфликтов.