Я полагаю, что выделенный и находчивый злоумышленник может выполнить атаку MITM и перехватить все запросы к общедоступным репозиториям Maven, осторожно внедряя вредоносный байт-код в артефакты JAR, а затем пересчитывая и предоставляя хэши SHA1.
Для клиента это выглядит как допустимый артефакт: двоичный JAR и SHA1 совпадают и будут одинаковыми, даже если они проверяют альтернативные зеркала.
Полагаю, единственное реальное решение - запросить центральные репозитории для поддержки HTTPS (и верю, что сам TLS не нарушен).
В качестве альтернативы практическим подходом может быть настройка прокси-сервера Maven (Artifactory или Nexus), обслуживаемого по HTTPS для внутренних клиентов. Это уменьшает поверхность атаки и означает, что вам просто нужно защитить линии связи от этого сервера до внешнего мира. Я бы периодически проверял, чтобы JAR-файлы и хэши на прокси-сервере совпадали с JAR-адресами и хэшами на общедоступных зеркалах, используя полностью независимую доверенную сеть.
Если вы действительно, действительно хотите быть в безопасности, вы не будете доверять двоичным файлам - вместо этого вы будете скачивать весь исходный код и просматривать их вручную перед их компиляцией самостоятельно, но это предполагает, что у вас достаточно квалифицированных ресурсов и времени для проведения проверок и для начала всей цепочки инструментов сборки.
Ну, безопасность в слоях, как они всегда говорят.