Если вы используете Central / JCenter напрямую (как вы упомянули в ваших комментариях), я бы рекомендовал никогда не создавать внутри инфраструктуры компании причину, которая открыла бы вектор атаки (теоретически).В таких случаях всегда опирайтесь на открытую инфраструктуру, такую как travis, circleci и т. Д.
Если кто-то хочет поместить вредоносный артефакт в Central (я не могу говорить за JCenter; если я правильно помню более или менее то же самое)в зависимости от сценария, который вы описали, это потребует доступа одного (плохого) человека к доступу к известной группе, которая содержит хорошо известные артефакты и наиболее важные из которых используются в широкой области.Это означает, что этот плохой человек должен иметь разрешение на публикацию артефакта в различных областях, включая подпись артефакта.
Хорошо, давайте предположим, что кто-то преодолел описанные выше барьеры.
Итак,Артефакт должен быть назван очень похожим на другие артефакты.И теперь кому-то нужно сделать конкретную опечатку, чтобы этот конкретный артефакт был поднят.Во-вторых, его нужно как-то выполнить (может быть возможны юнит-тесты / тесты на интеграцию).
Итак, в конце я бы сказал: теоретически да, практически очень маловероятно.
Но, конечно, 100% безопасность невозможна, поэтому общие советы:
- Передача всегда через https (как минимум, TLSv1.2)
- Проверка контрольных сумм артефактов (сбой сборки, если контрольные суммы не подходят )
- Использовать процесс проверки во время разработки
Поэтому я могу только рекомендовать использовать менеджер хранилища внутри компании и, конечно,используйте сканер безопасности, который проверяет наличие известных уязвимостей и т. д.
Кроме того, все менеджеры репозитория имеют возможность блокировать любые зависимости перед использованием и делают своего рода процесс одобрения возможным в вашей компании с недостатком времени, которое здесь "может "купить больше безопасности.