Большинство корпоративных Java-систем в России по-прежнему строятся вокруг стандартного набора инструментов:

• Maven / Gradle,

• публичные репозитории (Maven Central и зеркала),

• большое количество сторонних библиотек.

Такая схема отлично работает до тех пор, пока не встает вопрос контроля цепочек поставок ПО — то есть уверенности в том, что именно попадает в сборку и кто это произвел.

Обычно зависимости подтягиваются из публичных источников и проходят одобрения ИБ и юристов. Типичная модель современной Java-разработки:

build → dependency resolution → artifact download → packaging → deployment

Основная проблема такой схемы - это отсутствие доверенной границы. Поэтому ИТ-командам необходимо создавать внутренний доверенный контур поставки Java-артефактов, который:

1. гарантирует происхождение каждого бинарника,

2. исключает неконтролируемые источники,

3. интегрируется с существующими CI/CD без перестройки процессов,

4. соответствует требованиям регуляторов и стандартам безопасной разработки.

Для высоконагруженных платежных систем это перестает быть академической проблемой. В 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 проходит цепочку:

1. Проверка источника.

2. Сборка из исходных кодов.

3. Проверка лицензий.

4. Статический анализ.

5. Динамический анализ.

6. Антивирусное сканирование.

7. Проверка соответствия ГОСТ Р 56939-2016.

8. Криптографическая подпись.

9. Размещение в репозитории.

Важный момент:
все сборки воспроизводимые - это позволяет повторить процесс и получить идентичный бинарник, исключив «скрытые» изменения. Axiom Repo обеспечивает безопасную поставку более чем 4 000 библиотек и бинарных артефактов и каждый месяц пополняется еще на 1000 или более.

Процесс внедрения

Шаг 1. Перевод критичного контура

В первый этап попали наиболее нагруженные финтех-сервисы — платежный контур.

Шаг 2. Интеграция CI/CD

Настройка инфраструктуры сборки выполнялась один раз.
После этого все пайплайны продолжили работать без изменений логики сборки.

Шаг 3. Масштабирование

На текущий момент:

• 200 сервисов переведены,

• 400 приватных репозиториев подключены,

• вся Java-разработка планомерно переводится на единый доверенный контур.

Весь проект занял около одного месяца и был реализован внутренними силами команды.

Что реально изменилось

• Повышена безопасность цепочек поставок (минимизированы риски подобных атак).

• Исчезли неконтролируемые внешние источники зависимостей.

• Контроль происхождения каждого байта в сборке.

• Упростилась регуляторная отчетность.

• Повысилась предсказуемость релизов при высоком темпе разработки.

Почему это важно именно для Java? По нашим оценкам:

• ~90% финтеха в России работает на Java,

• ~70% корпоративных систем используют Java-стек.

Значит, контроль цепочек поставок именно Java-экосистемы становится ключевым элементом всей ИБ-стратегии.

Выводы для инженеров

1. Риски цепочек поставок — это инженерная проблема, а не только задача ИБ.

2. Решение должно быть встроено в существующие процессы, а не ломать их.

3. Контроль зависимостей невозможен без доверенного источника бинарников.

4. Для крупной Java-платформы репозиторий становится частью критической инфраструктуры.

Опыт ЕДИНОГО ЦУПИС показал, что контроль цепочки поставок в Java можно встроить в существующий процесс разработки без слома CI/CD и без остановки релизов. Фактически, это переход от модели «доверяем всему миру» к модели «доверяем только тому, что ��ожем воспроизвести и проверить». И для высоконагруженных систем это уже не вопрос «безопасности», а базовая инженерная практика: так же обязательная, как мониторинг, бэкапы и контроль отказов.

Подробнее разобрали кейс на вебинаре и подготовили запись. Если хотите расшифровку в виде статьи, пишите в комментариях под статьей или в нашем тг-канале.