Semgrep — это статический анализатор кода с человеческим лицом. В отличие от классических линтеров, он понимает структуру кода, а не просто гоняется по регуляркам. Правила Semgrep — это YAML-файлы, которые описывают паттерны: что искать, где искать и что считать проблемой.
Инструмент хороший. Но есть нюансы.
Как вообще работают правила Semgrep
По сути, вы описываете кусок кода, который хотите найти. Semgrep парсит исходник в AST, накладывает ваш паттерн и смотрит — совпадает или нет.
Простейшее правило для поиска использования eval() в Python:
rules:
- id: dangerous-eval
pattern: eval(...)
message: "eval() — это почти всегда плохая идея"
severity: WARNING
languages: [python]
Запускаете:
semgrep --config my-rules.yaml ./src
И получаете отчет по всем найденным совпадениям. Звучит просто, но мощь в деталях. Semgrep понимает, что eval(user_input) и eval(some_var) — это один и тот же паттерн. А ещё можно искать не только точные совпадения, но и вариации.
Например, правило для поиска SQL-инъекций:
rules:
- id: sql-injection
patterns:
- pattern: |
cursor.execute($QUERY, ...)
- pattern-not: |
cursor.execute("...", ...)
message: "Возможна SQL-инъекция — используйте параметризованные запросы"
severity: ERROR
languages: [python]
Здесь pattern-not исключает безопасные случаи, когда запрос — статическая строка. Вся магия Semgrep — в комбинировании таких условий.
Где брать готовые правила
Официальный реестр — registry.semgrep.dev. Там сотни правил на все случаи жизни: безопасность, производительность, стиль, баги. Можно подключить одной командой:
semgrep --config p/python ./src
semgrep --config p/security ./src
sempeg --config p/owasp-top-ten ./src
Правила поддерживает сообщество. Качество разное. Некоторые отличные, другие ловят ложные срабатывания на каждом шагу.
На GitHub тоже много коллекций. Искать по запросу "semgrep rules" или "semgrep-configs". Но тут как с npm-пакетами — надо смотреть, когда последний раз обновляли и сколько звёзд.
У Semgrep есть платная версия с SaaS-интерфейсом и дополнительными правилами. Бесплатная (OSS) покрывает 80% потребностей, если готовы сами настраивать CI/CD.
Плюсы Semgrep
Начну с хорошего, потому что его реально много.
Скорость. Semgrep быстрый. На проекте в 100k строк работает за секунды. Для сравнения: многие тяжёлые анализаторы считают минуты. Это значит, можно запускать на каждом коммите и не бесить разработчиков.
Простота написания правил. YAML читается легко. Паттерны выглядят как обычный код. Вот правило для поиска неиспользуемых переменных в JavaScript:
rules:
- id: unused-variable
pattern: |
var $X = $Y;
message: "Переменная $X, возможно, не используется"
severity: INFO
languages: [javascript]
Конечно, это упрощённый пример. Реальное правило сложнее. Но идея понятна — вы пишете примерно тот код, который хотите найти.
Мультиязычность. Поддерживается 30+ языков. Python, JavaScript, TypeScript, Java, Go, Ruby, PHP, C, C++, Rust, Swift — основные есть. Можно написать одно правило и применить его к проекту на трёх языках (с адаптацией синтаксиса).
Интеграции. Есть плагины для VS Code, IntelliJ, Vim. CI/CD интеграции для GitHub Actions, GitLab CI, Jenkins, CircleCI. В GitLab даже есть нативная поддержка Semgrep в составе GitLab Ultimate.
Открытый исходный код. Можете форкнуть, поправить под себя, хостить у себя. Данные не уходят на чужие серверы. Для многих компаний это критично.
Минусы Semgrep
Теперь о грустном. Честно — идеальных инструментов не бывает.
Ложные срабатывания. Главный враг любого статического анализатора. Semgrep не исключение. Написали правило для поиска "опасных" функций — получаете 50 предупреждений, из которых 3 реально важные. Остальное — легитимный код, который просто похож на проблемный.
Приходится либо тюнить правила, либо добавлять аннотации # nosemgrep, либо забивать. Все три варианта так себе.
Ограниченная глубина анализа. Semgrep — это pattern matching, не полноценный data-flow анализ. Он не прослеживает, как данные текут через программу. Если переменная с пользовательским вводом прошла через три функции и попала в SQL-запрос — Semgrep может не заметить.
Есть режим taint tracking в платной версии. Но он сложнее в настройке и всё равно уступает специализированным инструментам типа CodeQL.
Нужно писать правила самому. Да, есть реестр. Но под специфику вашего проекта всё равно придётся дописывать. А это время и экспертиза. Не каждый разработчик сядет и напишет хорошее правило с первого раза.
Сложные правила — это боль. Когда нужно отловить не тривиальный паттерн, а что-то вроде "функция вызывается с аргументом, который пришёл из HTTP-запроса и не был провалидирован", YAML превращается в простыню. Читаемость падает, поддержка становится адом.
Сравнение с альтернативами
| Инструмент | Тип | Плюсы | Минусы |
|---|---|---|---|
| Semgrep | Паттерн-матчинг | Быстрый, простой в настройке, открытый | Поверхностный анализ, ложные срабатывания |
| CodeQL | Data-flow анализ | Глубокий анализ, находит сложные уязвимости | Медленный, сложный в настройке, proprietary |
| SonarQube | Комплексный анализ | Много правил из коробки, хороший UI | Тяжёлый, платный для enterprise, свой сервер |
| ESLint/Pylint | Классические линтеры | Экосистема, плагины, быстрые | Ограничены одним языком, неглубокий анализ |
| Distiq | AI-анализ | Понимает контекст, мало ложных срабатываний | Требует интернет, подписка |
По моему опыту, Semgrep отлично работает как первый уровень защиты. Быстро прогнал на CI, отловил очевидные проблемы. Для глубокой безопасности нужен CodeQL или что-то подобное. Для стиля и качества кода — SonarQube или классические линтеры.
Когда Semgrep подходит
Небольшой или средний проект, команда до 20-30 разработчиков, нет выделенных security-специалистов. Semgrep даст 70% защиты за 20% усилий. Написали 10-20 правил под свой стек — и уже ловите баги до продакшена.
Стартапы, где скорость критичнее идеальной безопасности. Semgrep не тормозит разработку. Можно засунуть в pre-commit хук и не ждать окончания CI.
Open-source проекты. Semgrep бесплатный, его можно использовать без ограничений. Для опенсорса это важно.
Команды, которые хотят понять статический анализ. Semgrep — хороший входной билет. Научились писать правила — можно переходить к более сложным инструментам.
Когда Semgrep не подходит
Регулируемые индустрии: банки, медицина, госсектор. Там нужны глубокие аудиты, SBOM, формальные проверки. Semgrep слишком лёгкий.
Высоконагруженные проекты с микросервисной архитектурой. Когда 50 сервисов на разных языках общаются друг с другом — нужен анализ потока данных между сервисами. Semgrep работает в рамках одного репозитория.
Если нет времени на настройку. Из коробки Semgrep даст базу. Но реально полезен он становится после кастомизации. А это часы работы.
Практические советы
Начните с официальных правил из реестра. Не пытайтесь сразу написать свои. Посмотрите, что находит, что нет, какие ложные срабатывания.
Постепенно отключайте нерелевантные правила. Лучше 10 точных срабатываний, чем 100 с одним реальным багом. Разработчики перестанут обращать внимание на спам.
Добавляйте свои правила под специфику проекта. Используете определённый фреймворк? Напишите правила под него. Есть внутренние библиотеки? Правила под типичные ошибки при их использовании.
Вот пример правила для поиска неправильного использования внутреннего API:
rules:
- id: internal-api-misuse
patterns:
- pattern: |
ApiClient.call($METHOD, $ENDPOINT, ...)
- pattern-not: |
ApiClient.call(..., "/api/v2/...", ...)
message: "Используется устаревший API (/api/v1/) — мигрируйте на v2"
severity: WARNING
languages: [python, javascript]
Интегрируйте в CI, но не блокируйте мержи сразу. Сначала дайте команде привыкнуть, потом можно строже.
На одном проекте мы внедрили Semgrep за пару дней. Написали правил 15 под свой стек. Через месяц поймали багу, которая ушла бы в продакшен и стоила бы нам часов 10 отладки. Окупилось.
Но когда проект вырос до 50 сервисов, Semgrep перестал хватать. Часть правил переписали под CodeQL, часть отдали в SonarQube. А простые проверки оставили на Semgrep — он всё равно быстрый.
Сейчас мы в Distiq делаем AI-анализ кода. Подход другой: модель понимает контекст, а не просто ищет паттерны. Ложных срабатываний меньше, находки точнее. Для команд, которые хотят code review без головной боли с правилами — это вариант. Интеграция в GitLab, GitHub, GitVerse занимает минуты. Российский сервис, данные не уходят за рубеж.
Но если вы хотите полный контроль, бесплатные инструменты и готовы копаться в конфигах — Semgrep отличный выбор. Просто помните, что инструмент — это не процесс. Правила сами себя не напишут, а найденные баги сами себя не исправят.