Почему иностранные git-платформы – это риск для российских компаний

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

В этой статье мы рассмотрим два сценария использования иностранных Git-платформ (облако и self-hosted) и сопутствующие риски, а в конце честно пройдемся по контраргументам, потому что они есть, и игнорировать их опасно.

Две модели угроз

Прежде чем погружаться в детали, полезно зафиксировать рамку. Риски иностранных git-платформ распадаются на две принципиально разные модели в зависимости от того, как вы их используете:

• Облако (SaaS): «нас лишат доступа». Ваш код физически у вендора, и решение о вашем доступе принимает он.

• Self-hosted: «нам не дадут развивать и исправлять». Код у вас, но вы зависите от вендора в обновлениях, патчах безопасности и поддержке, а если платформа проприетарная, еще и не можете заглянуть внутрь.

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

Сценарий 1. Облако: когда рубильник не у вас

Санкционные риски – не гипотеза

Главный аргумент здесь самый приземленный: это уже было. GitHub принадлежит Microsoft и подчиняется юрисдикции США, а значит обязан исполнять требования OFAC и экспортного законодательства (EAR, ITAR).

Еще в 2019 году GitHub начал блокировать аккаунты разработчиков из санкционных регионов, включая Крым, Иран, Сирию, Кубу и Северную Корею. Заблокированные пользователи лишались закрытых репозиториев, доступа к Marketplace и управления платными организациями. Показательная деталь: VPN не спасал, потому что блокировались сами репозитории, а скачать или экспортировать их перед блокировкой было нельзя. Платформа анализировала IP-адреса и историю платежей, и даже простая поездка в подсанкционный регион могла стать причиной блокировки.

В апреле 2022-го волна пошла шире: GitHub заморозил аккаунты, связанные с попавшими под санкции российскими компаниями: в их число попали профили, ассоциированные со Сбером и Альфа-Банком, а также ряд индивидуальных разработчиков, которым приходили уведомления о возможной связи аккаунта с санкционным регионом.

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

Данные физически «лежат» за рубежом

Даже если вас никогда не заблокируют, остается вопрос соответствия нормативным требованиям. Код и сопутствующие данные на GitHub.com или GitLab.com хранятся на зарубежных серверах. Для многих российских компаний это прямой конфликт с законодательством:

• 152-ФЗ требует локализации персональных данных россиян на территории страны, а эти данные легко «утекают» в репозиторий – в конфигах, тестовых дампах, логах, комментариях;

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

Для enterprise-сегмента это не абстракция, а вопрос прохождения проверок и штрафов.

Скрытая зависимость от внешней инфраструктуры

Даже когда сам GitHub работает, вы завязаны на ворох сопутствующих внешних сервисов: это аутентификация (OAuth-провайдеры), CDN для раздачи статики и артефактов, пакетные реестры (npm, PyPI, container registry), Actions-раннеры и зеркала зависимостей.

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

Сценарий 2. Self-hosted: код у вас, но контроль – нет

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

Поддержка и владение кодовой базой

Для крупной компании поддержка от вендора – это не приятный бонус, а часть SLA. Когда что-то ломается в проде на 5000 разработчиков, нужен вендор, который возьмет инцидент в работу.

Иностранный вендор может прекратить поддержку российских клиентов в любой момент по санкционным или корпоративным причинам. И вот тут принципиально, владеет ли поставщик кодовой базой. Если вы работаете с отечественным разработчиком, который владеет исходниками своего продукта, он способен поддерживать и развивать его независимо ни от кого. Это и есть импортонезависимость в практическом смысле: не «мы поставили OpenSource и молимся», а «есть субъект, который отвечает за продукт и контролирует его эволюцию».

Патчи безопасности могут просто перестать приходить

Это, на мой взгляд, самый недооцененный риск self-hosted на иностранном ПО. Допустим, доступ к платформе у вас есть, она «крутится» на вашем железе. Но если вендор перестает пушить обновления в ваш регион – отключает доступ к репозиториям обновлений, к лицензионному серверу, к каналу дистрибуции патчей, – вы остаетесь «замороженными» на текущей версии.

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

Лицензионные риски

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

Конфликт юрисдикций

Под всеми перечисленными рисками лежит один фундаментальный: вендор обязан исполнять законы своей страны. А они могут прямо противоречить вашим интересам и российскому законодательству. Когда требование иностранного регулятора и интересы клиента из РФ сталкиваются, вендор выберет регулятора – иначе он сам окажется вне закона у себя дома. Вы в этом уравнении переменная, которой жертвуют.

А теперь контраргументы

У иностранных платформ есть сильные стороны.

GitHub и GitLab разрабатываются годами огромными командами. Это зрелые продукты с глубоким функционалом: продвинутый CI/CD, AI-ассистенты, code scanning, отлаженный code review, тысячи интеграций «из коробки». Отечественные платформы во многом догоняют, но по глубине отдельных фич отставание реально. Это честный минус миграции.

Есть еще один аргумент, который в разговоре про риски обычно замалчивают, – и он не про фичи и не про цену. GitHub – это не просто хостинг репозиториев. Это место, где «живет» мировое ИТ-сообщество. Миллионы OpenSource-проектов, issues с разбором архитектурных решений, pull request'ы от инженеров из лучших команд мира, обсуждения под CVE – все это не артефакты платформы, а живая среда, в которой разработчик профессионально растет. Когда команда работает только во внутреннем контуре, отрезанном от этого потока, она неизбежно начинает отставать – не по инструментам, а по мышлению: новые паттерны, подходы, библиотеки, которые становятся стандартом в мире, доходят с запозданием или не доходят вовсе. Это не паранойя в обратную сторону, а просто механика профессионального развития.

Полная изоляция от иностранных платформ решает проблему рубильника, но создает другую: инженерный вакуум. Поэтому взрослая позиция здесь – не «уйти полностью», а разделить: критический рабочий контур с исходниками и CI/CD – на независимой отечественной платформе, частное присутствие и участие в мировом комьюнити – там, где это комьюнити живет.

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

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

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

И еще один тезис, который любят приводить: «возьмем OpenSource self-hosted (GitLab CE, Gitea, Forgejo) – он бесплатный, его код открыт, вот и независимость». Аргумент сильный, но не абсолютный. Во-первых, открытый проект может сменить лицензию или закрыть часть функций: у GitLab, например, заметная доля возможностей живет только в проприетарной Enterprise-редакции и фирменном SaaS, и список этих функций вендор меняет по своему усмотрению. Во-вторых, «скачал и поставил» – это еще не поддержка: когда продукт «упадет» в проде, отвечать за инцидент будете вы сами без вендора за спиной. Открытый код снимает риск аудита и блокировки обновлений, но не снимает вопрос, кто будет это сопровождать и развивать.

Где здесь GitFlic

Если свести все описанное выше к одному критерию, он звучит так: платформой должен владеть субъект внутри вашей юрисдикции, способный независимо ее поддерживать и развивать. И тут стоит сказать про GitFlic, потому что он закрывает обе модели угроз сразу и по любопытной причине.

GitFlic – не форк GitLab, Gitea или чего-либо еще, а самостоятельная платформа, написанная с нуля на Java. На первый взгляд деталь техническая, но для разговора про независимость она ключевая. Форк наследует не только код, но и судьбу апстрима: его архитектурные решения, лицензионную политику, направление развития. Когда апстрим закрывает функции в проприетарную редакцию или меняет лицензию (привет, история с GitLab EE), форк оказывается в роли догоняющего: он вынужден или «тащить за собой» чужие решения, или болезненно расходиться с веткой.

Платформа, написанная с нуля, этой зависимости лишена: команда владеет всей кодовой базой целиком и определяет ее эволюцию сама.

Выбор Java вместо Ruby/Ruby on Rails (на которых построены GitHub и GitLab) – тоже не «косметика», а ставка на стабильность и производительность под нагрузкой крупных проектов, что для enterprise существенно.

По формальной стороне закрыты и регуляторные вопросы: GitFlic внесен в реестр отечественного ПО, развивается без иностранного участия и входит в экосистему «Группы Астра». Поставляется в двух вариантах: облачном и self-hosted с установкой на собственные серверы клиента, то есть закрывает оба сценария из этой статьи: и тех, кому нужен SaaS без риска блокировки, и тех, кому нужен полный контроль на своем железе с поддержкой вендора, владеющего кодом.

Функционально это не «голый» git-хостинг: на платформе есть CI/CD, RBAC-модель доступа, реестры пакетов и артефактов (по сути, отечественный аналог Nexus/Artifactory), инструменты безопасности. Это важно в контексте контраргумента про зрелость: переход с иностранной платформы не должен означать откат в функциональности.

Я не утверждаю, что GitFlic закрывает абсолютно все фичи GitLab один в один – взрослая позиция в том, что отдельные ниши у зарубежных гигантов глубже. Но по главному критерию этой статьи – кто держит рубильник и кто владеет кодом – GitFlic дает правильный ответ.

Что в итоге

Иностранная git-платформа для российской компании – это не вопрос «работает ли она сегодня». Сегодня она, скорее всего, работает. Вопрос в том, что в любой момент решение о ваших доступе, патчах и функциональности принимается не вами и не в вашей юрисдикции.

Две модели угроз – «отключат доступ» в облаке и «не дадут чинить» в self-hosted – закрываются одним решением: платформой, кодовой базой которой владеет субъект внутри вашей юрисдикции, способный поддерживать и развивать ее независимо. Это не про «отечественное ради отечественного», а про то, чтобы рубильник был у вас.

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

А раз так – выбор в пользу независимости перестает быть жертвой и становится просто здравым смыслом.

Эдуард Тихомиров,

технический директор GitFlic