Технологии Open Source. Обзор TAdviser 2025

В России нет финансовых, кадровых ресурсов, чтобы переписать все ПО, созданное в мире за многие годы. Тренд перехода отечественных компаний на открытое ПО сохраняется и усиливается. Доля готовых полнофункциональных OSS-продуктов (Open Source Software) растет.

Open Source остается основой глобальной кооперации в разработке. Преимущества, которые он приносит в мировую ИТ-индустрию, значительно перевешивают потенциальные риски.

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

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

Как рассказал Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio, открытое ПО имеет длинную историю как в инженерной, так и в производственной инфраструктуре: от операционных систем (Linux) до систем управления базами данных (PostgreSQL). Доверие к таким решениям складывается из практических механизмов: прозрачности, воспроизводимости и коллективного аудита. Например, OpenSSL, ядро Linux и PostgreSQL регулярно проходят независимые проверки, включая исследования университетов и консалтинговых компаний.

Алексей Варлаханов, руководитель отдела прикладных систем Angara Security, считает, что Open Source заслуживает доверия, прежде всего, благодаря прозрачности исходного кода, что позволяет проводить независимый аудит безопасности и модифицировать продукт под конкретные нужды организации.

Один из ключевых аргументов в пользу OSS-продуктов – любой желающий может посмотреть исходный код, пересобрать его, провести аудит с помощью инструментов статического, композитного или динамического анализа. Всё это снижает вероятность возникновения скрытых бэкдоров, неочевидных шпионских функций или недокументированных механизмов сбора данных, к примеру, телеметрии. Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio

Возможность изучить исходники на предмет уязвимостей выгодно отличает OSS от проприетарного кода, защищенного политиками вендоров.

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

С точки зрения доверенности и безопасности, наличие свободных компонентов является большим плюсом, поскольку возможности их исследования значительно выше, чем проприетарных, отметил Алексей Смирнов, председатель совета директоров «Базальт СПО». К тому же, благодаря доступности исходного кода в его исследовании принимает участие большое сообщество разработчиков.

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

Качество кода Open Source считается высоким за счет того, что его прорабатывает большое количество участников, у каждого из которых есть заинтересованность в надежности. Благодаря коллективной экспертизе разработчиков компания получает продукт с готовым базовым функционалом, экономя ресурсы на его создание.

Отсутствие зависимости от внешнего вендора – важное преимущество для критичных систем, уменьшающее риски внезапных изменений условий поддержки или прекращения выпуска продуктов. Команды внедрения могут сами выявлять и исправлять уязвимости, поддерживая высокий уровень безопасности при регулярном аудите. Алексей Варлаханов, руководитель отдела прикладных систем Angara Security

В контексте независимости от вендора, важным преимуществом OSS Зураб Белый, руководитель направления Java-разработки «Рексофт», считает отсутствие риска внезапного роста цен и возможность в любое время зафиксировать определенную версию продукта для самостоятельного развития.

Открытость кода позволяет изучить работу решения до внедрения, адаптировать его под задачи компании и самостоятельно контролировать безопасность, снижая зависимость от вендора. А для проверки безопасности применяются инструменты вроде SCA анализа (Software Composition Analysis), который выявляет компоненты с открытым кодом и оценивает их уязвимости… Сочетание Open Source технологий и профессиональной поддержки позволяет создавать эффективные и безопасные ИТ‑решения. Кирилл Дмитриев, менеджер продукта SelectOS, Selectel

Для нас Open Source остаётся технологической основой именно потому, что он прозрачен и проверяем: заказчик и вендор видят код и могут провести аудит. В корпоративном сегменте доверие усиливается благодаря COSS-модели: открытый код сочетается с поддержкой, безопасностью, обновлениями и ответственностью со стороны разработчика. Артем Ходько, заместитель директора сервисных проектов компании SMART technologies SOFT

Сергей Останевич, руководитель разработки платформы Tarantool (VK Tech) считает, что риском для безопасности является не открытость кода, а отсутствие или низкое качество проработки надежности кода.

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

Под капотом у проприетарного кода в среднем около 90% кода, взятого из репозиториев с открытом кодом. Никто экономически не может позволить себе создавать новые продукты с чистого листа: базовые вещи почти всегда берутся готовыми из Open Source библиотек. Грань размывается еще и тем, что за продуктом с открытом исходным кодом может стоять компания, оказывающая коммерческие услуги по сопровождению этого продукта, например платные версии Linux. Александр Пинаев, генеральный директор Swordfish Security

По словам эксперта, не бывает гарантированного уязвимого или неуязвимого проприетарного и открытого кода. Бывают компании и сообщества, которые уделяют или не уделяют время и внимание вопросам безопасности своих программных продуктов. Грамотные сообщества разработчиков проектируют свои системы с учетом требований безопасности, тестируют безопасность своих продуктов, используют сканеры уязвимостей, а также проводят bug bounty кампании.

Широко известны OSS-проекты, такие как Linux, Nginx, Kubernetes, OpenSSH, которые выбирают из-за ряда преимуществ и используют повсеместно крупные коммерческие компании. Эксперты считают, что эти программы являются более надёжными, чем многие проприетарные аналоги.

Идея о том, что OSS-продукты более уязвимы – миф. Действительно, есть риски, связанные с качеством управления проектом, атаками на цепочку поставок и отсутствием централизованной ответственности, но корректное управление ими делает использование OSS-продуктов более безопасным. Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio

По словам Алексея Варлаханова, руководителя отдела прикладных систем Angara Security, проприетарное ПО может скрывать свои уязвимости от внешнего анализа, что создает эффект «черного ящика» с неизвестными угрозами. Однако коммерческие продукты зачастую обладают более качественной и формальной поддержкой, что снижает эксплуатационные риски. Таким образом, опасения относительно OSS оправданы лишь частично, и все зависит от конкретных условий поддержки, процесса разработки и применения продуктов.

Можно сказать, что идея о потенциально более высокой уязвимости Open Source по сравнению с проприетарным софтом является ошибочным стереотипом. Действительно, публичность кода означает, что уязвимости видны всем, включая злоумышленников, но одновременно это обеспечивает гораздо более быстрый отклик сообщества и производителей на их устранение. Алексей Варлаханов, руководитель отдела прикладных систем Angara Security

Согласно прогнозу ИИМР от 2024 г., доля решений на основе открытого кода в общем объеме софта, используемого корпоративными клиентами (COSS/FOSS), к 2026 г. должно приблизиться к ⅔ при ⅓ у проприетарного софта. ^[1] Из конца года 2025-го эксперты смотрят на этот прогноз с разных ракурсов.

Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V, считает, что прогноз по-прежнему выглядит реалистично.

По нашим наблюдениям, использование решений на базе открытого ПО в бизнесе продолжает расти, но на более осознанном уровне, чем раньше. Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V

Максим Коробов, технический директор управления разработки клиентских интерфейсов в Т-Банке, считает несколько непрозрачным сравнивать доли вендорского и открытого ПО. По оценке эксперта, Open Source в России – это активность 50 тысяч инженеров в 50 крупных компаниях и 3000 живых проектов с активным сообществом и развитием. Коммерческий же сегмент может составлять 10% от этого объема.

По словам Виталия Секретенко, технического директора ГК «КОРУС Консалтинг», доля OSS в корпоративном сегменте растет не так проворно, как ожидали более ранние прогнозы, поскольку здесь требуются зрелые аналоги решений, компетенции и ресурсы на долгосрочную поддержку. При этом открытые решения часто не закрывают всех функций проприетарных систем, а бизнес осторожно относится к таким решениям с точки зрения ИБ.

Кирилл Бойко, технический директор K2 Cloud, считает, что старые прогнозы могут сбыться, но под этим будет пониматься уже не прямое использование глобального Open Source, а работа с его локализованными версиями от отечественных вендоров.

Что касается тезиса 2022 года о массовом переходе на открытое ПО к 2026 году[2] , изначально он вызывал сомнения. Крупные Open Source проекты не развиваются в вакууме – за ними, как правило, стоит бизнес, предоставляющий платную поддержку и сервисы. Максим Козлов, технический директор платформы GitFlic

Сергей Смирнов, руководитель кластера DevSecOps платформы «Сфера», отметил рост доли готовых полнофункциональных Open Source продуктов, например, операционных систем и СУБД.

Если говорить об отдельных компонентах, которые разработчики встраивают в свои системы, то здесь проникновение открытого кода максимальное. К 2026 году их доля в корпоративных продуктах действительно может приблизиться к 90%. Сергей Смирнов, руководитель кластера DevSecOps платформы «Сфера»

Эксперт отметил, что рост доли свободного софта, особенно в модели COSS, связан с переходом к сервисам: создавая решения на свободном ПО, предоставлять платформенные решения и сервисы очень удобно.

Как рассказал Алексей Смирнов, председатель совета директоров «Базальт СПО», доля проприетарного софта, в котором используются свободные компоненты, приближается к 100%. Трудно найти программное обеспечение, в том числе проприетарное, в котором бы не было значительной части свободного кода. Как минимум, все разработчики используют библиотеки.

По вопросу оценки объема рынка COSS Алексей Смирнов предположил, что тот равен объему всего софтверного рынка.

Алексей Захаров, директор по технологическому консалтингу Axiom JDK, также посчитал объем доли COSS от объема рынка разработки ПО в России. Исходя из оценки ₽4,97 трлн, эксперт предположил порядка ₽3 трлн.

Значительная часть этих решений, особенно отечественных, так или иначе построена на использовании Open Source компонентов. Алексей Захаров, директор по технологическому консалтингу Axiom JDK

Среди рисков замедления роста Алексей Захаров отметил аспект кибербезопасности. Бывают ситуации, когда релизы отменяются или откладываются из-за обнаружения критических уязвимостей.

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

По данным ФСТЭК, свыше 90% всех сертифицированных средств защиты информации в стране включают заимствованные программные компоненты с открытым исходным кодом.

Оpen Source перестал быть нишевой историей: это производственный инструмент, и компании идут не «в бесплатность», а в гибкость и технологический контроль – поэтому COSS-подход усиливает позиции на рынке. Артем Ходько, заместитель директора сервисных проектов компании SMART technologies SOFT

Оpen Source востребован там, где важны масштабирование, независимость и гибкость. Максимальная концентрация наиболее зрелых и широко внедренных OSS-продуктов приходится на инфраструктурный слой: контейнеризацию и оркестрацию (Docker, Kubernetes), DevOps-конвейеры (Git, Jenkins), системы управления базами данных (PostgreSQL, Redis, ClickHouse), виртуализацию, мониторинг (Grafana, Prometheus), резервное копирование и операционные системы.

По словам Виталия Секретенко, технического директора ГК «КОРУС Консалтинг», для компаний это означает, что инфраструктурный слой больше всего зависит от стабильного доступа к Open Source – и именно здесь потеря доступа к ПО может иметь наибольшее влияние на непрерывность ИТ-процессов.

Спектр применения Open Source гораздо шире: фактически вся современная разработка строится на Open Source решениях. Это и веб-фреймворки типа Spring для Java или React и Angular для фронтенда, и мобильная разработка на Flutter и React Native, и активно развивающиеся экосистемы для Data Science и ИИ. Зураб Белый, руководитель направления Java-разработки «Рексофт»

Не стоит забывать и о DIY-движении – проекты для IoT, самодельных устройств и автоматизации также в топе. Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V

В системном программном обеспечении роль свободного софта сейчас является преобладающей. В сегменте прикладного ПО сильные позиции у продуктов, не заточенных на узкие рынки – офисные пакеты, ВКС и т.п. А в сегменте узкоспециализированных отраслевых решений у свободного софта позиции, как правило, слабее. Алексей Смирнов, председатель совета директоров «Базальт СПО»

Если же смотреть на уровень компонентов и библиотек, то Open Source сегодня присутствует практически во всех типах разработки. Backend, frontend, веб-приложения, мобильные системы под Android и iOS – в любой современной классической разработке доля заимствованных OSS-модулей достигает в среднем превалирующую часть от всего объема кода.

Лидируют веб-фреймворки, за которыми следуют решения для мобильной разработки, инструменты Data Science и AI/ML, облачные и инфраструктурные платформы вроде Terraform и OpenStack, а также бэкенд-системы, такие как брокер сообщений Kafka.

Что касается языков программирования, в мировой практике используются практически все популярные языки. По статистике активности на платформах вроде GitHub лидером является JavaScript/TypeScript благодаря доминированию веб-разработки. На втором месте Python, чья популярность во многом обусловлена трендами в ИИ и Data Science. Далее следуют Java для enterprise-бэкенда (порядка 70% корпоративных систем и 90% в финтехе), Go для облачных технологий и C++ для высокопроизводительных вычислений. Вокруг них формируются наиболее зрелые экосистемы, на которые компании опираются при разработке и внедрении OSS-решений.

Согласно ежегодному аналитическому отчету GitHub, в 2025 году всплеск активности разработчиков совпал со структурным прорывом: впервые в августе 2025 года TypeScript обогнал Python и JavaScript, став самым используемым языком на GitHub, что отражает перестройку инструментария разработчиков и «знаменует самый значительный сдвиг в развитии языков программирования за более чем десятилетие».^[3]

Согласно нашему исследованию, в плане языков программирования тройку лидеров занимают Python, JavaScript и строго типизированный TypeScript, с тенденцией на рост популярности последнего. Не в последнюю очередь состав этой тройки обусловлен и проникновением AI и относительной простотой освоения. Следом идут традиционные Java, PHP, C#, C++ и более молодой Go. Среди набирающих популярность – Rust и HCL. Последний, строго говоря, является языком конфигурации, а не программирования, для реализации подхода Infrastructure as Code (IaC).[4] Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V

Хотя С/С++ остаются в лидерах, на сцену все активнее выходит Rust. Для быстрой разработки как бизнес логики, так и отдельных модулей универсального назначения широко применяется Golang. Сергей Останевич, руководитель разработки платформы Tarantool (VK Tech)

Почти под любой распространенный язык сейчас можно найти существенный пласт Open Source компонентов, которые используются в промышленных системах. Сергей Смирнов, руководитель кластера DevSecOps платформы «Сфера»

Большинство экспертов, опрошенных TAdviser, отмечают сужение участия российских разработчиков и компаний в глобальном Open Source сообществе из-за репутационных рисков, смещения фокуса бизнеса на импортозамещение и выживание под влиянием санкций. Блокировки доступа к зарубежным платформам, настороженное отношение и неформальные ограничения для российских программистов – эти репутационные и технические барьеры приводят к тому, что компании и специалисты переходят на российские платформы, создают импортозамещенные репозитории, активность переводится на закрытые внутренние разработки. Мировое сообщество все меньше готово принимать вклад россиян, которые в итоге переориентируются на локальные площадки, что приводит к обеднению обмена знаниями и консервации по отношению к мировой ИТ-экосистеме.

Компании, адаптируясь к новым экономическим условиям, перешли в «режим выживания». Фокус сместился на быструю, коммерчески ориентированную разработку, в том числе в рамках импортозамещения и госзаказа. В такой ситуации долгосрочные и менее предсказуемые с точки зрения окупаемости инвестиции в Open Source-проекты оказались не в приоритете.

Позволить себе выкладывать код в открытый доступ сегодня могут в основном крупные игроки с очень стабильным финансовым положением, считает Кирилл Бойко, технический директор K2 Cloud. По словам эксперта, для многих компаний, особенно работающих с госсектором, использование зарубежного Open Source стало сопряжено с рисками несоблюдения требований законодательства. В ответ на этот запрос рынка многие вендоры действуют по схеме «взять-доработать-сертифицировать-продать». Они берут готовое Open Source решение, «очищают» его, убирая лишнюю функциональность, и доводят до стабильной версии, нужной их клиентам. Потом этот продукт отправляется на сертификацию, и после этого он, по сути, перестает быть открытым. Его регистрируют как собственное проприетарное решение и продают под своим брендом, а обратно в Open Source сообщество эти доработки почти никогда не возвращаются. Это выгодно с коммерческой точки зрения, но не имеет ничего общего с идеологией открытого кода.

Как рассказал руководитель кластера DevSecOps платформы «Сфера» Сергей Смирнов, часть разработчиков переносит код и совместную разработку на российские платформы: там проще развивать проект без репутационных рисков. С точки зрения обмена кодом эти площадки уже закрывают базовые потребности, но скорость эволюции проектов на них чуть ниже из-за размера сообществ. Параллельно на GitHub, GitLab и других западных площадках происходит снижение активности именно тех команд, которые явно позиционируют себя как российские. Доступ для самостоятельного разработчика к таким репозиториям не был отключен, но российским компаниям доступ заблокирован.

Помимо этого, вклад российских программистов в международные проекты все чаще блокируется на неформальном уровне – их предложения по улучшению кода (pull-request'ы) не всегда принимаются к рассмотрению и интеграции, о чем рассказал руководитель направления Java-разработки «Рексофт» Зураб Белый.

По данным Smart Ranking, у крупных российских компаний в 2024 новых публичных репозиториев было на 16% меньше, чем в 2021 г., а в 2025 ожидается еще −7% год к году. ^[5] Среди причин уменьшения количества публикаций OSS-проектов от российских разработчиков на крупнейших площадках стоит отметить ограничения доступа к инфраструктуре Docker Hub из РФ, недоверие к размещенным там образам из-за растущих атак на цепочки поставок, рассказал Алексей Захаров, директор по технологическому консалтингу Axiom JDK.

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

В России 70% корпоративных систем работают на Java, а в финтехе – 90%. Для российских Java-разработчиков и компаний в 2025 году общемировые тренды дополнились уникальными вызовами и ответами на них.

В условиях санкций происходит активный переход на отечественные решения. Широкое распространение получает российская открытая среда разработки OpenIDE на базе популярной IntelliJ IDEA, которая всего за полгода с момента выпуска в апреле 2025 г. заняла заметную долю рынка (12% по опросу 2300 разработчиков в сообществе Спринг АйО). В критической инфраструктуре, например, в банках и топливно-энергетическом комплексе (ТЭК), идёт активный переход на отечественные JDK.

По данным исследования TechRadar Java 2025, проведенного JUG Ru Group в России, около 90% компаний в России используют фреймворк Spring для создания веб-приложений.^[6] Бесплатная OSS-поддержка для ключевых версий Spring Framework 5.3.x, 6.0.x и Spring Boot 2.7.x закончилась. Команда Spring перешла на модель полугодовых OSS-релизов, а долгосрочная поддержка (LTS) стала доступна только по платной подписке, которая недоступна для многих российских компаний из-за санкций.

Для российского бизнеса это событие имеет стратегическое значение. Spring наравне с Java служит ключевой технологической платформой для современной разработки. На ней построены финтех-системы, телеком-сервисы, ритейл и государственные системы. Алексей Захаров, директор по технологическому консалтингу Axiom JDK

Как рассказал руководитель направления Java-разработки «Рексофт» Зураб Белый, многие проекты, которые стали для россиян стандартом де-факто, контролируются иностранными компаниями. Если доступ к обновлениям или сообществу ограничат, это создаст серьезные проблемы для многих участников рынка.

Мы все больше становимся пользователями, а не соавторами Open Source. Возможности вносить свой вклад сокращаются, и это нарушает нормальный технологический обмен. При этом мы оказались в серьезной зависимости от крупных западных экосистем. Зураб Белый, руководитель направления Java-разработки «Рексофт»

По словам эксперта, практически вся инфраструктура, включая DevOps и системных архитекторов, построена на западном Open Source инструментарии, и зависимость носит системный характер. В обозримом будущем не видно предпосылок для того, чтобы от нее избавиться.

Прямой технологический обмен действительно снижается. Крупные российские вендоры выступают в роли посредников, поставляя на рынок уже доработанные и сертифицированные версии открытых продуктов. Кирилл Бойко, технический директор K2 Cloud

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

В первую очередь под удар попадают крупные интеграторы и вендоры – именно они больше всего зависят от постоянных обновлений и новых версий OSS. К тому же, крупные компании не могут через Open Source продвигать свой бренд работодателя.

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

В целом, данная ситуация отражается на всех участниках сообществ Open Source.

Руководитель кластера DevSecOps платформы «Сфера» Сергей Смирнов отметил, что для конечных заказчиков и разработчиков, которые используют открытый код, критичного ухудшения нет: альтернативные источники и каналы доступа сохранились.

Говорить о снижении технологического обмена не совсем корректно: российские команды продолжают активно пользоваться западными и, например, китайскими Open Source платформами. Сергей Смирнов, руководитель кластера DevSecOps платформы «Сфера»

Все оценки доли публикаций российских разработчиков на крупнейших площадках Open Source проектов носят очень условный характер, отметил Алексей Смирнов, председатель совета директоров «Базальт СПО». Эксперт пояснил, что не существует четких критериев того, является ли тот или иной разработчик российским.

Работа с домена в зоне .ru или .рф – не показатель, так как огромное количество разработчиков используют другие доменные зоны: например, .org и другие Других внятных критериев выделения отечественных разработчиков нет. В целом, российские разработчики, как принимали участие в международных проектах, так и принимают. Я и мои коллеги не отмечаем уменьшения такого участия. Алексей Смирнов, председатель совета директоров «Базальт СПО»

В качестве примера Алексей Смирнов привел работы по проверке ядра Linux и других компонентов, которые проводятся под эгидой ИСП РАН, и предположил, что количество патчей, которые отправляются в различные проекты, может даже увеличиваться.

Схожее мнение высказал Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V: данные с зарубежных площадок (GitHub и др.) в 2024 году указывали на замедление темпов прироста репозиториев от российских разработчиков, однако в значительной мере это связано с размытием критериев идентификации.

Многие проекты теперь публикуются анонимно или под нейтральными аккаунтами, чтобы избежать сложностей, а также с естественным переходом активности на локальные платформы. Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V

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

Наблюдаем, что публикация Open Source проектов продолжается в прежних темпах. При этом важно учитывать специфику таких публикаций: компании, как правило, открывают код SDK, плагинов и библиотек, но не публикуют исходный код своих конечных коммерческих приложений. Максим Козлов, технический директор платформы GitFlic

Ведущие ИТ-компании России размещают в открытом доступе репозитории с системами управления базами данных, подобная практика существовала и ранее, и значительных изменений в динамике таких публикаций не произошло. Об этом рассказал Максим Козлов, технический директор платформы GitFlic.

Рост обмена в сегменте AI/ML

Эксперты отмечают рост количества российских публикаций OSS-проектов по направлениям AI и ML. Это связано в том числе с повышением интереса к тематике ИИ во всем мире.

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

Для российских компаний работа с Open Source, с одной стороны, – необходимость, поскольку приходится брать готовые модели и дорабатывать их под свои нужды, создавать форки (копии репозиториев). Кроме того, публикация моделей – это про удобство и эффективность совместной работы. Ведь для обучения моделей необходимы мощные и дорогостоящие графические ускорители, часто объединенные в кластеры.

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

Рост решений в AI и ML кажется вполне закономерным трендом: по отчету GitHub Octoverse 2024, число новых проектов в генеративном ИИ выросло на 98% по сравнению с 2023 годом. Думаю, в этом году мы также увидим кратный рост. В этом смысле открытый код ускоряет инновации и делает их доступнее. Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V

Доступ к ключевым библиотекам на зарубежных площадках осложнён санкциями и ограничениями: периодически возникают сбои в работе репозиториев и облачных сервисов. Тем не менее, технические барьеры вполне преодолимы через зеркала, локальные прокси, альтернативные CI/CD и частичные локальные хранилища артефактов. Для ИТ-компаний все это выливается в возросшие операционные затраты.

Доступность неоднородна: Docker Hub для российских IP блокируется; GitHub Enterprise и Copilot официально не продаются в РФ; периодически меняются правила/потоки для PyPI и регистрационные процедуры для публикаций в Maven Central. Алексей Захаров, директор по технологическому консалтингу Axiom JDK

Зураб Белый, руководитель направления Java-разработки «Рексофт», отметил, что основные репозитории в основном доступны, хотя иногда бывают проблемы – временная недоступность или блокировка авторами отдельных пакетов. Критичные проекты вроде Linux или Kubernetes пока доступны без проблем, а специфичные библиотеки, включая некоторые модели для ИИ, уже заблокированы для российских IP.

Сейчас многие пользуются VPN как временным решением. Одновременно появляются и свои репозитории – тот же VK, Astra Linux и другие компании начинают открывать свои проекты. Процесс пошел, может быть, не так массово, но движение есть. Зураб Белый, руководитель направления Java-разработки «Рексофт»

Несмотря на отдельные инициативы (например, эксперимент по созданию национального репозитория), единой, массовой и популярной российской платформы, способной конкурировать с GitHub, на сегодня не существует. Кирилл Бойко, технический директор K2 Cloud

По мнению Виталия Секретенко, технического директора ГК «КОРУС Консалтинг», для бизнеса ключевой риск сейчас – вероятность внезапной недоступности тех библиотек, которые уже используются. Если критичный инструмент становится недоступным, это напрямую влияет на выпуск обновлений, стабильность и способность компании поддерживать работу собственных систем. Поэтому локальное дублирование артефактов и контроль цепочек поставки ПО становятся обязательным элементом архитектуры.

Чтобы избежать проблем в связи с прекращением обслуживания тех или иных сервисов, можно переводить наборы библиотек, которые используются в решениях компаний, под свое управление (fork). Сергей Останевич, руководитель разработки платформы Tarantool (VK Tech)

Как рассказал Алексей Захаров, директор по технологическому консалтингу Axiom JDK, просто копировать библиотеки – это не панацея, поскольку нет гарантии, что в исполняемых файлах нет вредоносного кода, так как нет возможности установить, откуда был взят исходник. Практика показывает, что надо создавать локальные репозитории библиотек и собирать все артефакты на доверенных компиляторах и конвейерах, как это рекомендует ГОСТ Р 56939-2024 по безопасной разработке, делать дополнительные антивирусные проверки.

Никаких ограничений на доступ к библиотекам нет и, по-моему, не предвидится. Не говоря уже о том, что есть российские репозитории, есть российские зеркала зарубежных репозиториев, да и к зарубежным ресурсам, к библиотекам никто не лимитировал доступ. Алексей Смирнов, председатель совета директоров «Базальт СПО»

Большая часть публичных библиотек по-прежнему доступна для российских пользователей, рассказал менеджер продукта SelectOS (Selectel) Кирилл Дмитриев. По мнению эксперта, так проявляется сама суть Open Source, поскольку доступ к библиотекам можно получить не только из репозитория разработчиков, но и с разного рода зеркал, форков и т.д.

Отдельные площадки вводят ограничения по IP, где-то усложнилась регистрация, но эти барьеры довольно легко обходятся – через VPN, зеркала и сторонние сервисы, которые агрегируют популярные компоненты. Сергей Смирнов, руководитель кластера DevSecOps платформы «Сфера»

Зеркала ставят в том числе в дружественных странах. Причем альтернативы появляются уже после введения блокировок. Об этом рассказал Максим Коробов, технический директор управления разработки клиентских интерфейсов в Т-Банке.

По словам Алексея Смирнова, председателя совета директоров «Базальт СПО», альтернативные источники из дружественных стран появляются, но важнее не дружественность страны, а наличие исходных кодов и свободной лицензии, которая позволяет и модифицировать, и использовать ПО.

По мнению Антона Атояна, заместителя генерального директора «СберТеха» и директора производства цифровой платформы Platform V, ситуация с доступностью библиотек для российских разработчиков в целом остается стабильной: глобальные репозитории библиотек вроде PyPI, NPM и Maven Central продолжают работать штатно. В РФ создано множество зеркал таких репозиториев библиотек, в первую очередь внутрикорпоративных, что является своеобразным гигиеническим требованием для ИТ-компаний.

Есть и публично доступные: например, такое стабильное зеркало доступно пользователям GitVerse. Кроме того, появляются инициативы в части совместной работы над актуальными и безопасными форками популярных Open Source проектов на отечественных платформах, включающие дополнительные проверки на уязвимости и наложение соответствующих исправлений. Антон Атоян, заместитель генерального директора «СберТеха» и директор производства цифровой платформы Platform V

Помимо активно растущих российских платформ, где размещаются полностью отечественные проекты, и хабов в других странах, перспективным направлением представляется экспертам китайский Open Source, где есть собственные Git- и CI/CD-платформы, реестры пакетов и экосистемы вокруг Huawei, Alibaba и Baidu, колоссальные ресурсы вкладываются в развитие свободного софта, в свои проекты на базе СПО, есть центры, где разрабатываются свободные программы. Помимо самостоятельных проектов, Китай стремительно наращивает долю участия в традиционных международных проектах разработки СПО. Вполне вероятно, что со временем китайские репозитории станут для РФ важной альтернативой. По крайней мере, интеграция китайского OSS в российский ИТ-ландшафт выглядит логичным продолжением текущих процессов.

Технические риски

Ключевое преимущество Open Source – открытость – является и одним из его слабых мест. Хакеры могут изучать те же исходники, что и разработчики, бизнес и независимые эксперты, находя слабые места. Стабильность и безопасность OSS не гарантированы изначально, они достигаются в процессе серьезнейшей работы.

Доверять Open Source продуктам, в целом, можно, но только в режиме «доверяй, но проверяй»: без системного подхода к информационной безопасности использование Open Source превращается в неоправданный риск. Риски связаны с цепочками поставок – независимые библиотеки могут содержать уязвимости. Встраивание вредоносного ПО и закладка уязвимостей в OSS-проекты может привести к взломам, утечкам информации, параличу бизнеса.

Каждое решение об использовании открытой библиотеки, базы данных или другого компонента должно приниматься осознанно. Важно понимать: используя готовую библиотеку, собранную из открытого исходного кода, мы не можем быть уверены в том, кем и как она была собрана, а также что именно содержится в её исходном коде – особенно когда речь идет о десятках тысяч строк. Максим Козлов, технический директор платформы GitFlic

Примером может служить атака на проект XZ Utils. В 2024 году вредоносный код был обнаружен в XZ Utils – библиотеке, используемой в системных утилитах Linux. Он попал в официальные релизы популярных дистрибутивов и выявлен лишь на финальном этапе. Алексей Захаров, директор по технологическому консалтингу Axiom JDK

Эксперты AppSec Solutions с помощью сервиса AppSec.Track зафиксировали более 40 тысяч уязвимостей в компонентах Open Source. А за последние 10 лет открытого кода с ошибками стало больше в 4,5 раза. Александр Пинаев, генеральный директор Swordfish Security

Узким местом является недостаток формальной технической поддержки и «распыленная ответственность». Как рассказал Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio, у OSS-продуктов, как правило, нет одного ответственного и состав команды часто меняется. У больших проектов есть зависимости из маленьких проектов, которые не в состоянии своевременно закрывать уязвимости по причине отсутствия ресурсов. Фактически зрелость ИБ-процессов в маленьких проектах недостаточна.

Отдельная проблема – так называемые «зомби-проекты», когда поддержка продукта прекращается, но уязвимости в нем остаются неисправленными. Зураб Белый, руководитель направления Java-разработки «Рексофт»

По мнению Алексея Варлаханова, руководителя отдела прикладных систем Angara Security, возможность вносить любые изменения в OSS несет риск ошибок и уязвимостей из-за недостатка формальной технической поддержки, которую вряд ли обеспечит сообщество на уровне коммерческих контрактов.

Когда вы скачиваете и используете свободный продукт – неважно, китайский, BRICS-овский или, например, английский, – вы должны четко осознавать, что за его развитие никто не отвечает. Никто не брал на себя обязательства и ответственность за его поддержку. Понятно, что такой продукт в принципе не может быть отнесен к категории доверенных, ведь «доверенность» обязательно предполагает не только безопасность, но и обеспечение длительного жизненного цикла. Алексей Смирнов, председатель совета директоров «Базальт СПО»

В случае обнаружения уязвимостей в программном продукте с проприетарным кодом, компания владелец приложит максимум усилий для их быстрого устранения. Кроме того, этой компании можно предъявить претензии, тогда как с сообщества разработчиков библиотек Open Source взятки гладки. Александр Пинаев, генеральный директор Swordfish Security

Юридические риски

Важным нюансом при использовании Open Source являются юридические риски, а именно лицензии библиотек. Как рассказал Александр Пинаев, генеральный директор Swordfish Security, некоторые типы лицензий предполагают раскрытие всего проприетарного кода, который вызывает OSS-библиотеку. Компонент с открытым исходным кодом при разработке может использовать другие компоненты, и так по цепочке. Разработчик думает, что он включил всего несколько компонентов, а на деле в проект из-за рекурсии попадает сотня-другая, причем это могут быть компоненты с сомнительной репутацией. В итоге проект получает целый спектр унаследованных уязвимостей.

С этим согласен Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio. По словам эксперта, неправильное соблюдение лицензионных требований при использовании OSS может вести к нарушениям интеллектуальной собственности, а зависимые компоненты могут быть вредоносными. Он напомнил про известный специалистам случай атаки на цепочку поставок, связанную с npm-пакетом еvent-stream, где разработчик модуля передал его на поддержку другому разработчику, а тот подменил модуль flatmap-stream на вредоносный.

Необходимо тщательно следить за лицензиями – не все из них разрешают коммерческое использование. Сложные цепочки зависимостей между библиотеками могут привести к проблемам: выход из строя даже небольшого компонента способен нарушить работу всей системы. Зураб Белый, руководитель направления Java-разработки «Рексофт»

Регуляторные риски

Есть и регуляторные риски. По словам Кирилла Бойко, технического директора K2 Cloud, рекомендации избегать ПО из недружественных стран препятствует развитию многих глобальных Open Source проектов. Поэтому компании перестраховываются и переходят на сертифицированные решения от российских вендоров, даже если «под капотом» в них тот же самый открытый код.

Зураб Белый, руководитель направления Java-разработки «Рексофт», отметил, что с точки зрения нормативного регулирования, запретов на использование иностранного Open Source нет: даже госструктуры и госкорпорации продолжают применять открытый код в своих системах. На уровне государства речь идет скорее о рекомендациях – методических материалах по контролю уязвимостей и управлению компонентами, а не о жестком делении на «разрешенное» и «запрещенное» ПО. И официальной долгосрочной стратегии именно по Open Source пока тоже нет.

Как рассказал Алексей Захаров, директор по технологическому консалтингу Axiom JDK, согласно пункту «б» указа президента РФ от 30.03.2022 №166 (ред. от 07.04.2025) «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», с 1 января 2025 г. органам государственной власти, заказчикам запрещается использовать иностранное ПО на принадлежащих им значимых объектах КИИ, если иное не установлено ФЗ. А согласно приказу Минцифры №21, в случае если ПО является свободно распространяемым, но сведения о нем не включены в единый реестр российского ПО, то такое ПО относится к иностранному.

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

По словам Алексея Захарова, необходимо опираться на доверенные репозитории и экспертизу разработчиков в используемых компонентах ПО. Для этого следует создать правила наполнения и использования доверенных репозиториев ПО и ввести требование цифрового паспорта для разработчиков критических информационных систем.

Государство двигается весьма поступательно со стороны ФСТЭК и Минцифры и создает нормы и правила по регистрации ПО и проведению его проверок, особенно для объектов КИИ. Алексей Захаров, директор по технологическому консалтингу Axiom JDK

По словам Артема Ходько, заместителя директора сервисных проектов компании SMART technologies SOFT, государство движется в сторону регулирования и стандартизации Open Source, усиливая переход КИИ и госкомпаний на решения с открытым кодом.

Это совпадает с нашей практикой: продукты SMART Linux, Haribda, STagry, ST.INT и решения SMART technologies SOFT изначально строятся на открытых технологиях, но поставляются как устойчивые корпоративные системы с поддержкой и контролем безопасности. Артем Ходько, заместитель директора сервисных проектов компании SMART technologies SOFT

Виталий Секретенко, технический директор ГК «КОРУС Консалтинг», отметил, что государство поддерживает развитие отечественных OSS-проектов в рамках политики технологической независимости. При этом роль государства смещается в сторону создания условий: повышение требований к безопасности, стимулирование публикации результатов госзаказа в открытом коде, поддержка профильных сообществ и развитие отечественных платформ.

Планы государства в этой сфере просматриваются довольно четко: это создание собственной, суверенной экосистемы Open Source, где российские разработчики могли бы обмениваться кодом на отечественных площадках. Кирилл Бойко, технический директор K2 Cloud

Алексей Смирнов, председатель совета директоров «Базальт СПО», напомнил о мировой практике, распространенной кроме Европы и США даже в Индии, когда работы, выполненные по госзаказу, подлежат обязательной публикации под свободной лицензией. Такой эксперимент был проведен и в России, но результаты остались не ясными. По словам эксперта, выбор лицензии – это вопрос выбора бизнес-модели тем или иным разработчиком, и можно было бы оставить этот вопрос на усмотрение ИТ-компаний.

Высокие требования к компетентности

Открытое ПО требует развитой экспертизы ИТ-команд для объективной оценки рисков использования и принятия мер по их минимизации. Чтобы сохранить устойчивость бизнеса, компании организуют централизованную проверку компонентов: вводят практики контроля библиотек на уровне ИБ, используют специализированные инструменты анализа зависимостей и уязвимостей, создают внутренние регламенты по выбору и обновлению Open Source. При наличии таких процессов остаточный риск сохраняется, но становится управляемым: критичные компоненты проходят аудит, а проблемные решения отсеиваются еще на этапе включения в продукт.

Риски связаны с цепочками поставок – независимые библиотеки могут содержать уязвимости. Мы закрываем это собственными зеркалами, DevSecOps-практиками, контролем зависимостей и формированием SBOM. Другой вызов – кадровый: эксплуатация OSS требует экспертизы, поэтому COSS-подход даёт компаниям устойчивость там, где чистый FOSS не справится. Артем Ходько, заместитель директора сервисных проектов компании SMART technologies SOFT

Переход на Open Source решения требует затрат на обучение персонала и адаптацию процессов, что тоже нельзя игнорировать. Алексей Варлаханов, руководитель отдела прикладных систем Angara Security

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

Важно ограничивать количество и обновлять версии используемых сторонних библиотек. Наилучшей практикой является создание контрольных списков зависимостей и настройка CI/CD-пайплайнов таким образом, чтобы зависимости автоматически проверялись на соответствие безопасности.

Чтобы продукт был доверенным, для его развития организация-разработчик должна обладать локализованными в РФ технологической инфраструктурой, кадрами и компетенциями. В том числе, соответствовать требованиям к процессам безопасной разработки (РБПО), которые разработаны ФСТЭК России. Эти требования в равной мере применимы как к свободным, так и к проприетарным продуктам.