SonarQube в Jenkins: первая неделя выявила SQL-инъекции и хардкод паролей в 12 репозиториях

Разговоры про DevSecOps у клиентов периодически заходят в тупик примерно на одном месте: «у нас и так есть code review, зачем ещё инструменты». Три недели назад один такой разговор закончился иначе - решили проверить гипотезу практикой. Подключили SonarQube к Jenkins-пайплайнам трёх команд разработки. Первая же неделя расставила точки над i.

Что подключали и как

У клиента - три команды с разным стеком: одна пишет на Java (Spring Boot, микросервисы), вторая - PHP-монолит с хорошей историей, третья - Node.js, относительно свежий проект. Итого около 20 репозиториев. Jenkins давно в ходу, пайплайны описаны, но безопасность в них - нулевая. Сборка, тесты, деплой на staging - и всё.

SonarQube 7.6 Community Edition встали на отдельную виртуалку. Для Java и PHP сканеры шли из коробки, для Node.js взяли плагин SonarJS. В Jenkins добавили stage sonarqube-analysis после unit-тестов и до деплоя. Quality Gate выставили не блокирующим - решили первые две недели просто смотреть что выплывет, не ломая существующий процесс деплоя. Команды об этом знали.

Интеграция заняла день на первый проект и несколько часов на каждый последующий.

Что нашли за неделю

Итог первых семи дней: уязвимости нашлись в 12 из 20 репозиториев. Это не было приятным сюрпризом.

SQL-инъекции - самая неловкая находка. В PHP-монолите, которому несколько лет, нашлось несколько мест, где пользовательский ввод шёл в запрос без параметризации. Не в каком-то тёмном углу - в одном случае это был поиск по каталогу, который используется ежедневно. Код смотрели несколько разработчиков, но уязвимость проскакивала.

Хардкод credentials - это уже история про привычки. В конфигурационных файлах, прямо в репозитории, нашлись пароли к базам данных, API-ключи к сторонним сервисам, токены. Часть из них - к тестовым контурам, часть - к продакшн-сервисам. SonarQube нашёл их банальным поиском по шаблонам: password=, api_key =, secret. Не нужно было ничего хитрого. Просто раньше никто не смотрел этим взглядом.

Небезопасная десериализация в Java-сервисах - SonarQube пометил несколько мест, где данные из внешних источников десериализовывались без валидации. Серьёзность зависит от контекста, но флаги правомерны.

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

Почему code review это не поймал

Вопрос не риторический - команды реально практикуют ревью, не для галочки. Ответ скучный: reviewer смотрит на логику, архитектуру, читаемость. Паттерн $query = "SELECT * FROM users WHERE id=" . $_GET['id'] при беглом чтении выглядит как рабочий код. SQL-инъекцию здесь заметить можно, но надо специально искать.

Хардкод паролей в конфигах - ещё проще не заметить. Если файл большой, если review идёт по diff и этот кусок не менялся - глаз скользит мимо.

SAST работает иначе: он делает один и тот же прогон по всей кодовой базе, каждый раз, с одинаковой внимательностью. Усталости нет, контекстного переключения нет.

Что стало сложным

Шум. В первые дни SonarQube выдал несколько сотен замечаний суммарно по всем проектам. Часть из них - реальные проблемы, часть - false positive, часть - технический долг, который команды уже знали и сознательно не трогали. Разбирать этот список и расставлять приоритеты - работа, которую нельзя переложить на инструмент. Инструмент нашёл, приоритизировать пришлось людям.

Второй момент: у команд возник закономерный вопрос - что делать с тем, что уже в репозитории. Исторический долг по безопасности обычно выглядит как длинный список, устранить который одним спринтом невозможно. Нужно договариваться о приоритетах и сроках - это отдельная организационная история.

Где сейчас

Quality Gate пока не переведён в режим блокировки - дали командам две недели на то, чтобы разобраться с критическими находками до того, как пайплайн начнёт падать на них. Credentials из репозиториев уже выносятся в Vault - эту работу начали сразу, не дожидаясь. SQL-инъекции закрываются патчами в текущих спринтах.

Checkmarx рассматривали как альтернативу - он работает с коммерческим саппортом и дает чуть меньше шума на Java. Но для старта Community Edition SonarQube оказался достаточным, чтобы понять масштаб проблемы.

Если у вас в компании есть аудит кода и инфраструктуры только в формате ручного ревью - стоит поставить вопрос, что именно ревью не видит. Ответ может удивить.