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

Именно на этот сценарий и нацелена настройка GitLab: найти дыру в Spring-приложении до того, как она попадёт в основную ветку, и сделать это так, чтобы security-гейт не превращался в вечный красный стоп-сигнал.

Что произошло

Речь идёт не о новой атаке на конкретный банк или сервис, а о рабочем способе ловить уязвимости в Java-проектах раньше релиза. Автор исходного материала показывает, как в GitLab включить автоматический dependency scanning для Spring Boot-сервиса и заставить его видеть не только прямые, но и транзитивные зависимости.

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

Для примера берут Spring Boot-проект на Maven и заведомо уязвимую версию commons-text 1.9 с CVE-2022-42889, известной как Text4Shell. Это удобный тестовый кейс: в реальном проекте такая библиотека нередко всплывает не в pom.xml, а глубже по графу зависимостей.

Как это сделано

Автор предлагает перейти на новый движок dependency scanning в GitLab — тот, что работает через SBOM и шаблон V2. Старый путь через Gemnasium уже уходит в прошлое, а значит, тянуть его в новый проект смысла мало.

Ключевой момент — полный граф зависимостей. Если сканер видит только верхний слой pom.xml, он может пропустить ту самую библиотеку, которая пришла через стартер или служебный модуль. Поэтому в пайплайне важно либо дать GitLab сам собрать граф на стадии pre, либо явно экспортировать его в maven.graph.json, чтобы анализатор получил нормальную картину состава проекта.

Автор отдельно подчёркивает, что зелёный отчёт ещё не значит полную безопасность. Если GitLab ушёл в fallback-режим и посмотрел только на объявленные вручную зависимости, пайплайн формально выполнится, но часть риска останется за кадром. Здесь и нужен аккуратный контроль артефактов: gl-dependency-scanning-report.json, CycloneDX SBOM и список уязвимых компонентов.

Хорошая практика — проверять не только наличие отчёта, но и то, что в нём действительно видна транзитивная зависимость. Это тот случай, когда сухая автоматика экономит дни ручной проверки после инцидента. Похожий подход к раннему контролю цепочки поставок мы уже разбирали в материале про скрытые трояны в GitHub.

Кого затронуло и какие последствия

Тема в первую очередь касается команд, которые пишут на Java и держат Spring Boot в продакшене: финтех, e-commerce, внутренние корпоративные сервисы, API для партнёров. Для таких проектов транзитивные зависимости — обычная история, а не редкий сбой.

Последствия тоже знакомые. Уязвимость может жить месяцами в чужом модуле, не попадать в ручные ревью и выстрелить уже после релиза. Если при этом у команды нет нормального dependency scanning, поиск превращается в аврал: кто подтянул библиотеку, откуда она приехала, какие сервисы реально затронуты.

Важно и то, что GitLab позволяет смягчить шум. Автор как раз ставит задачу не валить пайплайн на каждой CVE, а отделять опасные находки от устаревших, но безобидных пакетов. Для команд с плотным циклом поставки это критично: если security-гейт ломает каждую сборку, его быстро начинают игнорировать.

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

Что сейчас делать читателю

Если у вас Spring-проект и GitLab CI уже стоит, начните с двух вещей. Сначала проверьте, что зависимостный граф реально собирается и попадает в отчёт. Потом убедитесь, что pipeline показывает не только прямые, но и транзитивные зависимости.

Дальше настройте правило так, чтобы сборка не падала на любой найденной CVE. Лучше отделить критичные уязвимости от всего остального и использовать гейт только там, где риск действительно тянет на блокировку релиза.

Если проекта ещё нет в таком режиме, не ждите, пока всплывёт новый Log4Shell. Чем раньше вы научите CI видеть состав сборки, тем меньше шансов, что чужая библиотека тихо доедет до прода.

  • Проверьте, подключён ли в GitLab новый dependency scanning через SBOM и шаблон V2.
  • Убедитесь, что в отчёт попадает полный граф Maven, а не только pom.xml.
  • Найдите в gl-dependency-scanning-report.json транзитивные библиотеки и проверьте, видны ли они как отдельные компоненты.
  • Посмотрите, не падает ли pipeline на каждой CVE без разбора.
  • Отдельно проверьте критичные зависимости, которые пришли через стартеры и служебные модули.
  • Для удалённой работы используйте дополнительные меры защиты корпоративного трафика и переписки.

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

Поделиться: