Open source, или компоненты с открытым исходным кодом сегодня лежат в основе значительной части корпоративного ПО и государственных ИС. По некоторым оценкам, около 90% российских компаний используют открытый исходный код в своей ИТ-инфраструктуре. Готовые библиотеки и фреймворки позволяют не разрабатывать базовый функционал с нуля, а строить приложения их готовых строительных блоков, что позволяет существенно сокращать сроки и стоимость создания продуктов. Однако вместе с преимуществами бизнес получает новую зону риска: приложения начинают зависеть от компонентов, разработчиков, репозиториев и инструментов, которые не контролируются напрямую. Это связано с тем, что нет возможности проконтролировать весь процесс сборки от исходного кода библиотек и до конечного артефакта. Чаще всего разработчики скачивают готовые компоненты — артефакты в уже скомпилированном виде, как правило, из зарубежных источников. Чем больше таких элементов в ПО, тем выше риск атак: злоумышленники могут попытаться использовать любой из элементов цепочки и скомпрометировать его, используя уязвимости или «закладки», что позволит использовать эту ситуацию как точку входа в корпоративную инфраструктуру с целью остановки ключевых процессов, повреждения или кражи данных.
Что скрывается за цепочкой поставки ПО
Цепочка поставки ПО давно вышла за пределы исходного кода конкретной библиотеки. В нее входят публичные репозитории, пакетные менеджеры, транзитивные зависимости, SDK и плагины, CI/CD-компоненты, контейнерные образы и механизмы доставки обновлений. С каждым годом число атак на цепочки поставок растет, по данным «Лаборатории Касперского», в 2025 году с такими атаками столкнулись 31% компаний в мире и 35% в России. А по данным компании CodeScoring, за 2025 год количество вредоносных компонентов выросло на 1000%. Такой тренд имеет экспоненциальную динамику, по отношению к трем годам ранее, где рост составил около 700%. Атакующему не обязательно искать уязвимость непосредственно в инфраструктуре компании. Иногда достаточно скомпрометировать один из компонентов, которому она доверяет. Все чаще целью становятся разработчики, репозитории и системы сборки, ведь через них можно незаметно внедрить вредоносный код в легитимное ПО.
Компоненты с открытым исходным кодом — это не только исходный код, который разработчик может изучить и изменить. Часто компания использует уже готовые артефакты, опубликованные в публичных репозиториях, которые, как правило, находятся на ресурсах за пределами РФ. В этом случае разработчик не контролирует весь процесс их формирования и не может самостоятельно гарантировать полное соответствие конечного артефакта исходному коду. В артефакт могли быть внесены вредоносные изменения — как на этапе разработки, так и в процессе сборки. Поэтому защищать нужно не только собственный код, но и всю цепочку поставки ПО.
Где возникает основной риск
Риски могут возникать почти на любом этапе, начиная от разработки и публикации исходного кода до сборки и доставки готового продукта. Один из очевидных сценариев: компрометация аккаунта разработчика или мейнтейнера в случаях отсутствия регистрации домена. Зарегистрировав домен на себя, злоумышленник получает доступ к репозиторию и может изменить исходный код или выпустить новую версию уже известного пакета и его артефактов. При автоматическом обновлении такой компонент способен попасть в корпоративную среду, а проверка средствами композиционного анализа покажет его как безопасный.
Злоумышленник может взломать аккаунт разработчика или намеренно войти в сообщество и действовать изнутри. Например, в 2024 году обнаружился бэкдор в XZ Utils, который создал участник проекта. В течение двух лет он активно участвовал в развитии проекта, помогал исправлять ошибки, позже ему дали статус со-мейнтейнера с правом менять код. Получив доверие сообщества, он начал внедрять вредоносный код в набор утилит.
Неподдерживаемая библиотека — это еще одна зона риска. Важно понимать, поддерживается ли сам проект, насколько активно развивается и есть ли команда, способная оперативно выпускать исправления. Если библиотека фактически заброшена, новая уязвимость может остаться без патча.
Отдельный риск связан с системой сборки и CI/CD, такие средства, как Maven и Gradle, являются источниками риска. Они связывает исходный код, зависимости и готовый продукт и при этом часто имеют доступ к инфраструктуре. Если скомпрометирована система сборки или ее компоненты, злоумышленник может изменить конечный артефакт еще на этапе его формирования.
Потенциальная угроза для продукта может скрываться и во фреймворках, которые используются в разработке. Например, Spring — это один из популярных фреймворков среди российских Java-разработчиков. По информации из опроса «State of Java» компании JUG Ru Group, Spring используется в более чем 80% проектов. И устаревшая версия фреймворка может затронуть сразу большое количество систем, поскольку теперь сообщество устраняет уязвимости только в актуальных версиях Spring. Отделу ИБ и разработчикам важно смотреть не только на наличие известных уязвимостей, но и контролировать статус поддержки версий сообществом разработчиков. Особенно это актуально сейчас, когда после выпуска обновлений бесплатная поддержка истекших версий для разработчиков прекращается и рекомендуется переход на коммерческую поддержку, которая недоступна в России.
ИИ тоже имеет значение
Генеративный ИИ уже стал неотъемлемой частью процесса разработки: он помогает писать код, подбирает необходимые библиотеки или фреймворки. При этом возникает дополнительный риск: модель может предложить внешний компонент, не учитывая, есть ли в нем известные уязвимости, насколько актуальна используемая версия и применима ли поддержка на территории России. Конечно, многое зависит от конкретной ИИ-модели и ее источников данных. Одни модели работают на основе ранее известных примеров кода, другие уже умеют обращаться к внешним ресурсам и получать более актуальную информацию. При этом сам факт рекомендации библиотеки не означает, что она прошла проверку безопасности. ИИ ориентируется прежде всего на то, работает ли предложенный код, но не проверяет зависимости.
Для проверки можно использовать композиционный анализ. Он позволяет определить версии подключенных библиотек и проверить их на наличие известных уязвимостей через базы БДУ ФСТЭК, NIST и др. Еще один подход — настроить ИИ на использование доверенных библиотек из внутреннего репозитория, а не произвольных компонентов из публичных источников. В таком случае модель будет работать только с тем набором компонентов, который уже прошел необходимые проверки.
Безопасность цепочки поставок — общая ответственность поставщика и разработчика
Сегодня вопрос контроля ИБ-рисков особенно актуален. Проверка компонентов, актуальности версии, контроль сборки в защищенной среде и быстрого устранения уязвимостей — не всегда задача только службы ИБ. Безопасность цепочки поставок требует совместной работы нескольких команд и компаний, которые постоянно взаимодействуют с целью повышения уровня защиты ПО.
Отдел ИБ определяет правила использования доверенных компонентов, закрепляет политики, по которым нужно использовать определенное ПО из соответствующих доверенных источников, и контролирует их соблюдение. Далее к работе подключается команда архитекторов и разработчиков, а также платформенная команда (DevOps), которая должна обеспечивать безопасные среды запуска и платформу. В ее задачи должна входить реализация ИТ-инфраструктуры на надежных и доверенных компонентах, которые будут соответствовать требованиям российского законодательства в части безопасности. Разработка, в свою очередь, несет ответственность за работу продукта. Для этого вся команда разработки должна быть погружена в продукт и разбираться в том числе и в аспектах безопасности.
Конечный продукт должен отвечать всем требованиям, как с точки зрения ИБ, так и с точки зрения функционала.
Как строить защиту цепочки поставок через компоненты с открытым исходным кодом
Исследовательская компания Gartner в своем отчете «Leader’s Guide to Software Supply Chain Security» 2024 года предложила выстраивать защиту цепочки поставок в три этапа: Curate, Create и Operate (управление, создание, эксплуатация). Такой подход позволяет контролировать происхождение программного продукта и снижать риски на каждом этапе цепочки.
Первый этап — выбор доверенных компонентов: библиотек, фреймворков, компиляторов, интерпретаторов и средств проверки. Важно заранее понимать происхождение компонентов и использовать те, безопасность которых можно контролировать.
Второй этап — безопасная разработка и анализ кода. Здесь необходимо контролировать весь процесс создания ПО — от исходного кода до готового артефакта, используя инструменты анализа и практики SSDLC (Secure Software Development Life Cycle) в соответствии с требованиями ГОСТ Р
Третий этап — контроль эксплуатации. Даже безопасный программный продукт может оказаться под угрозой, если его развернуть на уязвимой инфраструктуре. Поэтому необходимо контролировать и среду, в которой ПО запускается.
Такой подход позволяет встроить безопасность непосредственно в процесс разработки. Кроме того, если используемые компоненты, их версии и требования к инфраструктуре заранее определены и документированы, аудит становится проще: не нужно каждый раз заново проверять весь технологический стек.
Чем больше внешних компонентов используется в продукте, тем сложнее контролировать их происхождение, изменение и состояние. Поэтому при оценке безопасности цепочки для противодействия атак важно рассматривать весь путь, который проходит код до промышленной эксплуатации. Часть рисков и нагрузки с команд разработки можно снять за счет работы с проверенным поставщиком, который обеспечивает контроль безопасности и целостности компонентов на всех этапах их жизненного цикла.
При выборе поставщика ПО необходимо учитывать не только функциональность решения, но и происхождение решений. Предпочтение следует отдавать российским поставщикам ПО, которые контролируют весь исходный код компонент и обеспечивают безопасный процесс и сборки на основе ГОСТ Р
Функциональным заказчикам рекомендуется включать в требования к ПО пункты соблюдения правил контроля и проверки кода и использования доверенных компонентов, что можно реализовать путем создания доверенных источников компонент для подрядных организаций на уровне компаний или индустрий.
