Большинство корпоративных Java-систем в России по-прежнему строятся вокруг стандартного набора инструментов:
Maven / Gradle,
публичные репозитории (Maven Central и зеркала),
большое количество сторонних библиотек.
Такая схема отлично работает до тех пор, пока не встает вопрос контроля цепочек поставок ПО — то есть уверенности в том, что именно попадает в сборку и кто это произвел.
Обычно зависимости подтягиваются из публичных источников и проходят одобрения ИБ и юристов. Типичная модель современной Java-разработки:
build → dependency resolution → artifact download → packaging → deployment
Основная проблема такой схемы - это отсутствие доверенной границы. Поэтому ИТ-командам необходимо создавать внутренний доверенный контур поставки Java-артефактов, который:
гарантирует происхождение каждого бинарника,
исключает неконтролируемые источники,
интегрируется с существующими CI/CD без перестройки процессов,
соответствует требованиям регуляторов и стандартам безопасной разработки.
Для высоконагруженных платежных систем это перестает быть академической проблемой. В 2025 году ЕДИНЫЙ ЦУПИС принял решение формально и технически закрыть этот класс рисков на уровне всей Java-платформы.
Результатом стал перевод инфраструктуры Java-разработки на доверенный отечественный репозиторий компонентов — Axiom Repo из экосистемы продуктов Axiom JDK.
Поделимся инженерными деталями этого перехода.
Масштаб и требования
ЕДИНЫЙ ЦУПИС — это платежный сервис в регулируемой индустрии развлечений, для отрасли он является обязательной точкой интеграции.
Технические вводные:
200 сервисов на Java-стеке,
400 приватных репозиториев,
~25 млн клиентских кошельков,
2,5 млн платежей в сутки,
более 20 релизов ежедневно,
SLA 99,99%.
Любое нарушение целостности цепочки сборки релизов здесь - это риск регуляторного или операционного инцидента, который нельзя допустить.
Архитектура решения
Общая схема
Source code
↓
Контролируемая сборка
↓
Аудит → анализ → проверка лицензий → подпись
↓
Axiom Repo (внутренний репозиторий)
↓
CI/CD → сборки сервисов → прод
Ключевые элементы
Axiom Repo выступает как:
полная замена публичных репозиториев,
единая точка поставки Java-артефактов,
хранилище только проверенных бинарников.
Поддержка стандартных протоколов:
Maven
Gradle
Для команд разработчиков это выглядит как обычный репозиторий, закрытый аутентификацией:
<repository>
<id>axiom-repo</id>
<url>https://repo.internal</url>
</repository>Никаких изменений в коде сервисов, только замена источника зависимостей.
Внутренняя «кухня» репозитория
Каждый артефакт в Axiom Repo проходит цепочку:
Проверка источника.
Сборка из исходных кодов.
Проверка лицензий.
Статический анализ.
Динамический анализ.
Антивирусное сканирование.
Проверка соответствия ГОСТ Р 56939-2016.
Криптографическая подпись.
Размещение в репозитории.
Важный момент:
все сборки воспроизводимые - это позволяет повторить процесс и получить идентичный бинарник, исключив «скрытые» изменения. Axiom Repo обеспечивает безопасную поставку более чем 4 000 библиотек и бинарных артефактов и каждый месяц пополняется еще на 1000 или более.
Процесс внедрения
Шаг 1. Перевод критичного контура
В первый этап попали наиболее нагруженные финтех-сервисы — платежный контур.
Шаг 2. Интеграция CI/CD
Настройка инфраструктуры сборки выполнялась один раз.
После этого все пайплайны продолжили работать без изменений логики сборки.
Шаг 3. Масштабирование
На текущий момент:
200 сервисов переведены,
400 приватных репозиториев подключены,
вся Java-разработка планомерно переводится на единый доверенный контур.
Весь проект занял около одного месяца и был реализован внутренними силами команды.
Что реально изменилось
Повышена безопасность цепочек поставок (минимизированы риски подобных атак).
Исчезли неконтролируемые внешние источники зависимостей.
Контроль происхождения каждого байта в сборке.
Упростилась регуляторная отчетность.
Повысилась предсказуемость релизов при высоком темпе разработки.
Почему это важно именно для Java? По нашим оценкам:
~90% финтеха в России работает на Java,
~70% корпоративных систем используют Java-стек.
Значит, контроль цепочек поставок именно Java-экосистемы становится ключевым элементом всей ИБ-стратегии.
Выводы для инженеров
Риски цепочек поставок — это инженерная проблема, а не только задача ИБ.
Решение должно быть встроено в существующие процессы, а не ломать их.
Контроль зависимостей невозможен без доверенного источника бинарников.
Для крупной Java-платформы репозиторий становится частью критической инфраструктуры.
Опыт ЕДИНОГО ЦУПИС показал, что контроль цепочки поставок в Java можно встроить в существующий процесс разработки без слома CI/CD и без остановки релизов. Фактически, это переход от модели «доверяем всему миру» к модели «доверяем только тому, что можем воспроизвести и проверить». И для высоконагруженных систем это уже не вопрос «безопасности», а базовая инженерная практика: так же обязательная, как мониторинг, бэкапы и контроль отказов.
Подробнее разобрали кейс на вебинаре и подготовили запись. Если хотите расшифровку в виде статьи, пишите в комментариях под статьей или в нашем тг-канале.
