О том, как обеспечить безопасность цифровой инфраструктуры на базе открытого ПО в условиях атак на цепочки поставок, рассказывает глава комитета по информационной безопасности АРПП "Отечественный софт", директор по стратегии и развитию технологий Axiom JDK Роман Карпов.

Современная цифровая инфраструктура немыслима без программного обеспечения с открытым исходным кодом. Однако широкая зависимость от сторонних компонентов и библиотек создает беспрецедентные риски. С 2019 по 2023 год количество атак на цепочки поставок ПО в мире выросло на ошеломляющие 742%. Только за 2023 год было зафиксировано 245 тыс. инцидентов, что вдвое больше, чем за три предыдущих года вместе взятых, а общий ущерб для бизнеса превысил $46 млрд. Среди наиболее резонансных случаев — атака на MOVEit Transfer, которая нанесла убытки в $9,9 млрд, и компрометация 3CX, в результате которой пострадали 600 тыс. пользователей.

В 2024 году вредоносный код был обнаружен в XZ Utils — библиотеке, используемой в системных утилитах Linux. Он попал в официальные релизы популярных дистрибутивов и был выявлен лишь на финальном этапе. В 2025 году была зафиксирована атака через подмену пакета в публичном репозитории JavaScript-библиотек. Вредоносная зависимость оказалась частью криптографического модуля, который применялся в финансовых и блокчейн-приложениях.

Проблема кроется в самой природе современной разработки: 95% приложений состоят в том числе из внешних библиотек, а 79% кода приложений очень редко обновляется, что расширяет поверхность атаки для злоумышленников. Они используют такие методы, как подмена названий пакетов или регистрация подменных доменов (typosquatting) и внедрение вредоносных библиотек через публичные репозитории (dependency confusion), а также атакуют сами инструменты сборки и доставки ПО. Один из ярких примеров — атака на инфраструктуру JetBrains TeamCity в 2023 году. Обеспечение безопасности требует комплексного подхода и контроля на всех этапах жизненного цикла программного обеспечения, включая инструменты сборки, разработки и работы со сторонними зависимостями.

Как контролировать цепочки поставок, чтобы противостоять угрозам

В России важным шагом в сторону системной цифровой безопасности стало принятие стандарта ГОСТ Р 56939-2024, который регламентирует процессы разработки безопасного программного обеспечения (РБПО). Этот документ описывает требования к безопасной разработке и рекомендует внедрение соответствующих практик, включая использование инструментов, реализующих принципы Secure Development Lifeсycle (SDL).

Основные элементы таких процессов включают:

• Статический анализ кода — позволяет выявлять потенциально опасные участки в исходном коде, которые могут привести, например, к переполнению буфера или выполнению произвольного кода.
  
• Динамический анализ — применяется для поиска уязвимостей в уже работающем программном обеспечении. Сюда относится, например, фаззинг, при котором система тестируется случайными или некорректными входными данными для выявления ошибок и нестабильного поведения.
  
• Композиционный анализ (SCA) — обеспечивает контроль используемых сторонних компонентов, включая проверку зависимостей на наличие уязвимостей, проблем с лицензированием и рисков компрометации.
  
• Верификация сборок — подтверждает соответствие исполняемых файлов исходному коду, исключая возможность скрытых изменений или подмен в процессе сборки.

Центральную роль в реализации этих требований играет композиционный анализ (SCA). Его инструменты позволяют сканировать не только прямые, но и транзитивные (косвенные) зависимости программного проекта, выявляя известные уязвимости (CVE) посредством анализа версий, зависимостей от других компонентов и лицензии каждого компонента. Яркий пример критичности SCA – уязвимость Log4Shell в библиотеке Log4j, которая показала, как одна проблемная компонента может угрожать миллионам систем по всему миру. Именно поэтому в регулируемых отраслях, таких как госструктуры, финтех или промышленность, интеграция композиционного анализа в CI/CD-конвейеры сборки ПО становится неотъемлемой частью процесса разработки.

"Цифровой паспорт" ПО как основа анализа уязвимостей

Одним из ключевых инструментов композиционного анализа является SBOM (Software Bill of Materials). Он представляет собой структурированный перечень всех компонентов, входящих в программный продукт: библиотеки, зависимости, версии. Это своего рода "цифровой паспорт" ПО, позволяющий оценить его уязвимости и управлять рисками.

Современные инструменты позволяют автоматически создавать SBOM-файлы на каждом этапе сборки. Они поддерживают международные стандарты - например, SPDX (инициатива Linux Foundation) и CycloneDX (инициатива OWASP) - и легко интегрируются в популярные CI/CD-системы, такие как GitLab или Jenkins. Более продвинутые решения не ограничиваются генерацией: они обеспечивают непрерывный мониторинг компонентов на наличие уязвимостей, формируют отчеты по критичности (на основе рейтингов CVSS) и дают рекомендации по устранению рисков.

Однако важно понимать: сам по себе SBOM не делает ПО безопасным. Это инструмент визуализации и анализа, но не защиты. Он не исключает возможность целенаправленных атак, когда вредоносный код внедряется в легитимные компоненты еще на этапе разработки или сборки. Так, например, в случае с атакой на SolarWinds вредоносный код был подписан действующими сертификатами. Кроме того, SBOM не защищает от подмены исполняемых файлов или компрометации исходных репозиториев. Поэтому SBOM — важный, но не единственный элемент стратегии безопасности.

Доверенные общедоступные репозитории библиотек на территории РФ

Публичные репозитории, такие как Maven Central, npm и PyPI, содержат десятки тысяч библиотек, среди которых могут быть устаревшие, уязвимые или намеренно вредоносные компоненты. Кроме того, эти источники подвержены геополитическим рискам. Блокировка доступа к GitHub для российских компаний в 2022 году показала, насколько уязвимой может быть внешняя инфраструктура поставок программного обеспечения.

При этом ни одна организация не может самостоятельно проверить все множество используемых зависимостей. Их слишком много, и для тщательной оценки требуются значительные ресурсы, время и экспертиза. Поэтому все большее значение приобретает создание доверенных источников компонентов, размещенных в российской юрисдикции и неподконтрольных внешнему регулированию. А решением может быть локальный репозиторий с верифицированными артефактами, прошедшими аудит безопасности и контроль воспроизводимости.

В этом направлении ведут работу "Сбер", "Ростелеком", правительство Москвы, Т1. Они создают репозитории для своих корпоративных задач. Рыночные игроки, члены Ассоциации "Отечественный софт", например, "Базальт СПО" и "РЕД СОФТ", предлагают тиражируемые решения - репозиторий "Сизиф" и RedRepo. Инженеры Axiom JDK реализуют промышленный подход к созданию репозитория для Java, который будет доступен всем пользователям в России. Каждый артефакт собирается из исходных кодов с обязательной проверкой лицензий, аудитом безопасности и соблюдением требований ГОСТ по безопасной разработке. Особое внимание уделяется воспроизводимости сборок - это позволяет исключить скрытые или непредсказуемые изменения в коде.

Доверенный репозиторий легко интегрируется в существующую инфраструктуру разработки, полностью совместим с Gradle и Maven, а также постоянно расширяется с учетом запросов клиентов. С экономической точки зрения внедрение такого решения, по стоимости сопоставимого с годовой зарплатой инженера по безопасности, способно предотвратить многократно большие убытки, связанные с простоями, штрафами и репутационными рисками.

Выводы

Обеспечение безопасности цифровой инфраструктуры на базе открытого ПО в условиях атак на цепочки поставок требует комплексного подхода, объединяющего три ключевых элемента:

1. Четкие регламенты и стандарты, такие как ГОСТ по безопасной разработке (РБПО), которые определяют требования к процессам создания и сопровождения программного обеспечения на всех этапах его жизненного цикла.

2. Мощные инструменты контроля, такие как композиционный анализ (SCA) и автоматизированная генерации SBOM в стандартных форматах (SPDX, CycloneDX) для понимания состава ПО и контроля уязвимостей.

3. Надежная внутренняя инфраструктура компонентов - доверенные репозитории, размещенные внутри страны, которые обеспечивают доступ к верифицированным библиотекам и исключают зависимость от внешних и санкционных рисков.

По прогнозам аналитиков, в 2025 году почти половина организаций в мире (45%) столкнется с атаками на цепочки поставок в ПО. В России ответом на этот вызов становится тренд на создание независимых локальных репозиториев библиотек, в том числе доступных в виде продукта или сервиса.

Безопасность открытого ПО — это не разовая проверка, а непрерывный процесс. Он включает в себя верификацию используемых компонентов, постоянный мониторинг на основе SBOM, регулярные обновления, взаимодействие с сообществом разработчиков, устранение уязвимостей и информирование пользователей.

Важную роль в этом процессе играет Институт системного программирования Российской Академии наук (ИСП РАН), ведущий разработку современных стандартов и инструментов анализа ПО. Это видно, в том числе, по обратной связи, получаемой в рамках Дней РБПО, которые проводит АРПП "Отечественный софт" на базе крупных ИБ-вендоров, таких как "Лаборатория Касперского", "ИнфоТеКС", Positive Technologies. Диалог между разработчиками, аналитиками и регуляторами помогает выработать общие подходы, ускорить реализацию требований и снизить затраты.

Отдельное значение имеет инфраструктура доверия. Использование отечественных решений для централизованных доверенных репозиториев позволяет минимизировать риски уже в источнике угроз - на уровне загрузки сторонних библиотек, что критически важно для построения надежных приложений и устойчивой цифровой инфраструктуры государства.