🛡 Почему зелёный отчёт GitLab не гарантирует безопасность зависимостей Когда в декабре 2021-го грянул Log4Shell, половина команд по всему рынку не знала, есть ли у них этот компонент. И это норма для Maven: вы не добавляли опасную зависимость в pom.xml — она приехала транзитивно, через стартер или библиотеку логирования на втором-третьем уровне. По данным Сергея Прощаева из OTUS, именно это — главный канал риска для Spring-приложений. И именно здесь ломается большинство внедрений сканирования зависимостей в GitLab. Проблема в режиме отката. Без файла блокировки (которого у Maven по умолчанию нет) новый движок GitLab на основе CycloneDX может переключиться на анализ pom.xml. И тогда он увидит только явные зависимости. Формально пайплайн зелёный, отчёт есть, галочка стоит — а транзитивная commons-text 1.9 с CVE-2022-42889 (Text4Shell, CVSS 9.8) в сканирование не попала. Худший вид безопасности — тот, что создаёт ложное ощущение, будто всё проверено. Решение из статьи — явная генерация графа maven.graph.json через `mvn dependency:tree -DoutputType=json` и передача его как артефакта в пайплайн. Тогда анализатор видит полное дерево, а не верхушку. Дальше — борьба с шумом. На живом проекте сканер выдаст десятки Critical и High, и команда просто привыкнет игнорировать красный крестик. Статья показывает связку из двух механизмов: анализ достижимости кода (отсекает уязвимости в библиотеках, до которых ваш код физически не дотягивается) и политика безопасности, которая блокирует не «всё красное», а только дельту — новые уязвимости, привнесённые конкретным merge request. Именно `vulnerability_states: newly_detected` и `severity_levels: critical` — узкий, обороняемый порог, против которого тяжело возразить. Отдельно в материале разбирают свежий вектор Java‑Class‑Hijack, представленный на SCORED в 2025-м. Вредоносный класс с тем же полным именем, что у легитимного, прячется глубоко в транзитивной зависимости и при определённом порядке classpath подменяет поведение приложения. На немецком ковид-трекере Corona‑Warn‑App так дотянулись до логики подключения к базе через крошечную библиотеку валидации JSON с третьего уровня вложенности. Это не теория — это эксплуатация, для которой нужна полная картина того, что попадает в JAR. Настройка инструмента — больший фактор риска, чем его отсутствие. Когда я вижу зелёный пайплайн в проекте, где не проверяли, попала ли Text4Shell в отчёт SBOM, я задаю один вопрос: вы убедились, что сканер действительно видит commons-text, или просто довольны цветом иконки? Потому что красный отчёт хотя бы вызывает вопросы, а зелёная ложь — усыпляет. #AppSec #GitLab #DependencyScanning #SCA #DevSecOps