Мы привыкли воспринимать Maven-зависимость как готовый кусок кода, который просто добавляется в проект. Но на самом деле вместе с зависимостью мы доверяем её автору гораздо больше.

Код из зависимости может выполняться не только в самом приложении. Он может запускаться во время сборки, через плагины, процессоры, тесты и другие инструменты. А значит, потенциально получает доступ к машине разработчика или CI: файлам проекта, переменным окружения, credentials и сети.

Это уже не теория. Атаки на цепочку поставок происходили в самых разных экосистемах: от компрометации популярных npm-пакетов до инцидентов вроде Log4Shell и XZ Utils. Для Java отдельно исследуются атаки, при которых вредоносная зависимость может подменять классы другой библиотеки и менять поведение приложения.

Сам Maven прямо описывает эту модель безопасности: при сборке мы доверяем не только pom.xml, но и коду, зависимостям и репозиториям, из которых они загружаются.

Недавний инцидент с Android библиотекой RxPermissions

У старой версии извесной библиотеки RxPermissions под привычными Maven-координатами обнаружился другой артефакт. Внешне это была та же зависимость, но внутри находился дополнительный build-time код, который мог загружаться Android Lint во время сборки.

То есть проблема уже не в том, что библиотека делает внутри Android-приложения. Потенциально она получает возможность воздействовать на среду, в которой это приложение собирается.

Именно поэтому новые зависимости стоит рассматривать как часть цепочки поставки, а не просто как ещё одну строку в build.gradle. Минимальный набор мер довольно простой: - Проверять происхождение и содержимое артефактов; - Фиксировать контрольные суммы зависимостей; - Ограничивать разрешённые Maven-репозитории; - Использовать Dependency Verification; - Ограничивать сетевой доступ CI; - Согласовывать новые и особенно неожиданные зависимости.

Зависимость — это не просто библиотека. Это код, которому вы разрешаете участвовать в сборке вашего проекта.