Накануне Дня РБПО, который прошел 10 декабря 2025 года и модератором которой выступила компания Axiom JDK, мы провели опросы инженерного сообщества, чтобы выявить, как разработчики воспринимают безопасность цепочки поставки ПО и требования РБПО.

Результат оказался однозначным: большинство разработчиков сосредоточены на качестве кода, тестировании и отказоустойчивости — но почти не воспринимают себя участниками цепочки поставки ПО.

Именно здесь возникает ключевой разрыв между инженерным взглядом и реальными рисками бизнеса.

Что показали опросы

1. Безопасная разработка = качество кода

66% разработчиков в первую очередь связывают безопасность с качеством кода, аккуратной работой с данными, минимумом зависимостей и код-ревью.

2. Отказоустойчивость - второе по значимости направление

47% связывают безопасность с тестами на сбои, мониторингом, резервированием и устойчивой архитектурой.

3. РБПО воспринимается как важный регуляторный механизм только частью аудитории

Только 32% связывают безопасную разработку с выполнением требований регуляторов.

Менее 10% считают РБПО «формальностью ради аудита».

Замечательная, но тревожная цифра: почти 20% разработчиков уверены, что безопасность не относится к их зоне ответственности.

Самое важное: разработчики не считают себя частью цепочки поставки ПО

• Более 50% не считают безопасность поставки артефактов своей задачей.
• 42.8% считают, что это работа ИБ.
• Только 7.1% готовы думать о безопасности цепочек поставки.
• Около 30% продолжают брать зависимости прямо из интернета.

В итоге 93% инженеров не связывают свою работу с контролем зависимостей, артефактов, репозиториев и сборочных процессов.

Это логично с точки зрения инженерной культуры: разработчики решают технические задачи. Но современные угрозы показывают, что основные атаки идут не на код, а на цепочку поставки.

Почему цепочка поставки становится критичной для бизнеса

Сегодня атаки всё чаще нацелены на зависимости, репозитории и инструменты сборки.
Компрометация одной зависимости может незаметно внедриться в тысячи инсталляций и затронуть продакшн.

Риски для компаний очевидны:

• Технические: внедрение вредоносного компонента в продукт.

• Финансовые: простой сервисов, восстановление, расследования.

• Репутационные: потеря доверия клиентов и партнёров.

Безопасность цепочки поставки ПО становится не менее важной, чем качество кода.

Реальные кейсы атак на цепочки поставок

Кейс 1. Атака на зависимости Python в “СБЕР Еаптека” (2022)

Злоумышленник разместил в PyPI библиотеки-клоны популярных пакетов - классический typosquatting. Разработчики случайно скачали вредоносную зависимость, которая:

• собирала системную информацию;
• загружала дополнительные файлы;
• передавала данные удалённому серверу;
• создавала бэкдор в окружении разработки.

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

Этот кейс показал: атака может пройти через любую зависимость — даже в крупной компании с сильной службой ИБ.

Кейс 2. MavenGate - атака через захват заброшенных Java-библиотек (выявлена в 2024)

Исследователи обнаружили, что злоумышленник может выкупить просроченный домен, связанный с groupId Java-библиотеки, и выпускать под ним “обновлённые” версии. Они выглядят легитимно, и Maven/Gradle могут автоматически загрузить их при сборке.

Особенности MavenGate:

• это не разовая атака, а уязвимость в самой архитектуре экосистемы;
• пакет может быть заброшен, домен — утрачен, а контроль — перехвачен;
• угроза существует годы и выявлена только в 2024-м.

Кейс 3. Typosquatting в Maven Central: поддельные JAR-файлы (2021–2023)

Механизм атаки прост:

злоумышленник публикует библиотеку с названием или groupid, отличающимся 1–2 символами от популярного пакета, чтобы сборщик скачал вредоносный JAR при опечатке разработчика.

Атаки фиксировались ежегодно:

• 2021 — серия поддельных библиотек (Checkmarx);

• 2022 — волна пакетов-клонов, ориентированных на Android;

• 2023 — новые вредоносные имитации популярных библиотек.

Причина повторяемости проста: публичные репозитории принимают пакеты автоматически и не проверяют происхождение.

Российская регуляторика РБПО: зачем это вводится

С 2024–2025 годов в России активно внедряются требования (ГОСТы) РБПО для разработчиков, интеграторов и владельцев ИТ-инфраструктуры.

Задача регуляторики - не ограничение бизнеса, а защита от уже известных сценариев атак, формирование “инженерной гигиены”.

Государство реагирует на:

• рост атак на открытые репозитории;
• попытки внедрения вредоносного кода в зависимости;
• отсутствие контроля происхождения ПО в критичных системах;
• необходимость защищать локальные разработки в условиях импортозамещения.

РБПО смещает фокус с «формального выполнения требований» на реальную цель:
не дать злоумышленнику попасть в продукт в том числе через зависимость.

Почему РБПО важно даже там, где нет регуляторных требований

Даже если компания не попадает под контроль ФСТЭК, угрозы остаются те же.

РБПО — это практика инженерной гигиены:

• знать происхождение артефактов;
• использовать доверенные репозитории;
• исключать внешние источники без проверки;
• автоматизировать проверки;
• выстраивать прозрачные цепочки сборки.

Это не бюрократия, а защита бизнеса от инцидентов, которые могут стоить миллионов.

Почему Axiom JDK делает ставку на РБПО

Опросы показывают: разработчики готовы к изменениям, если инструменты простые, прозрачные и не создают дополнительной нагрузки.

Поэтому экосистема Axiom JDK развивает решение - Axiom Repo (доверенный репозиторий Java-библиотек), который:

• обеспечивают безопасность цепочки поставки артефактов Java-разработки;
• минимизируют ручные действия (проверяем библиотеки за вас и гарантируем их целостность и соответствие исходникам);
• дают прозрачность происхождения артефактов;
• упрощают выполнение регуляторных требований;
• работают как защита и ускорение разработки, а не как ограничение.

Как Axiom Repo усиливает безопасность поставки ПО

Axiom Repo - первый в России доверенный промышленный репозиторий Java-компонентов, который формирует прозрачную и контролируемую цепочку поставки ПО. Он заменяет небезопасные публичные источники зависимостей, обеспечивает сборку артефактов во воспроизводимой среде, проверку подписи и контроль происхождения каждой библиотеки. Это снижает риск supply-chain атак и автоматически помогает компаниям соответствовать требованиям регуляторов.

Переход на Axiom Repo проходит бесшовно для разработки: инфраструктура Maven и Gradle работает в привычном режиме, но уже в доверенном контуре. Именно поэтому ЕДИНЫЙ ЦУПИС выбрал решение для критичных финтех-сервисов: компания ежедневно выпускает до 20 релизов, и проводит до 30 тысяч платежей в минуту и Axiom Repo обеспечивает их стабильное и своевременное прохождение, усиливая безопасность и технологическую независимость платформы. Доверенный источник Java-компонентов с прозрачной цепочкой поставки позволяет контролировать зависимости, сохранять предсказуемость разработки и эксплуатации, а также полностью соответствовать SLA и требованиям регуляторов, включая PCI DSS и стандарты ЦБ РФ — без дополнительной нагрузки на команды.

Заключение

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

Чем раньше компании начнут относиться к цепочке поставки как к критическому элементу разработки, тем устойчивее и надёжнее будет бизнес в новых условиях.