На GitHub случился сбой
Вчера, 14 июля 2026 г., в работе хостинга для ИТ-проектов GitHub произошел сбой. В течение примерно двух часов пользователи из России не могли открыть сайт веб-сервиса и получить доступ к репозиториям. Примерно в 13:00 по московскому времени проблемы прекратились.
По словам директора Центра разработки решений по контролю безопасности ПО Solar appScreener АО "Солар Секьюрити" Антона Прокофьева, без VPN GitHub не работал ни как сайт, ни как хранилище репозиториев. Он отметил, что последствия для российских разработчиков оказались масштабными.
"Прервалась работа с кодом — невозможно загрузить, обновить и синхронизировать проекты. В ряде проектов остановились автоматизированные процессы сборки и тестирования, привязанные к GitHub, что задержало выход обновлений. Также стала недоступной техническая документация, которая нередко ведется прямо в репозиториях", - рассказал он.
Сложности с доступом отметил и директор по продуктам ПАО "Группа компаний "Базис" Александр Курач, но, по его словам, они не оказали существенного влияния на работу компании. Он отметил, что для крупных разработчиков такие ситуации не являются критичными, так как важный корпоративный код, инфраструктурные репозитории и внутренние процессы разработки не завязаны на публичный GitHub.
"Мы используем внутренние контуры, self-hosted-решения, резервные репозитории и собственные инструменты управления кодом. Поэтому проблемы с доступом к GitHub создают неудобства, но не останавливают ключевые процессы разработки", - заметил он.
Схожую историю рассказал технический директор ООО "РеСолют" (GitFlic входит в ПАО "Группа Астра") Эдуард Тихомиров. По его словам, сбой не нанес прямого операционного ущерба компании, так как ее рабочие репозитории находятся во внутреннем контуре.
"Мы прекрасно понимаем, что для большой части российских разработчиков, которые еще не перенесли проекты на суверенные решения, эти два часа стали реальной остановкой работы", - рассказал он.
Руководитель продукта AppSec.Track ООО "АппСек Солюшенс" (AppSec Solutions) Михаил Макаров сослался на ежегодный отчет GitHub Octoverse за октябрь 2025 г., согласно которому на долю России приходится около 4,16 млн аккаунтов (9-е место в мире). Однако он заметил, что если убрать из списка неактивные, учебные и дублирующие профили, то реальное количество аккаунтов составит от 700 тыс. до 1 млн, при этом большая часть из них уже пользуется импортозамещенными платформами.
Последствия от сбоя, по оценкам его коллег, можно разделить на три условные группы: краткосрочные (дни-недели), среднесрочные (месяцы) и долгосрочные. К первым относятся остановка синхронизации кода у команд с репозиториями на GitHub, обрывы CI/CD-пайплайнов, невозможность скачать зависимости и релизы напрямую, а ко вторым — рост рисков в цепочке поставок ПО.
"Рост рисков в цепочке поставок ПО (software supply chain) — главный практический риск. Когда прямой доступ к оригинальным репозиториям и реестрам пакетов затруднен, разработчики начинают тянуть зависимости из непроверенных зеркал и форков. Это идеальная среда для typosquatting-атак, подмены пакетов и внедрения вредоносного кода. Контроль состава ПО (SCA/OSA), проверка целостности артефактов и использование доверенных внутренних реестров из "хорошей практики" превращаются в обязательное условие безопасной разработки. Также происходит замедление обновлений безопасности. Затрудненный доступ к патчам и security advisory открытых проектов увеличивает окно эксплуатации известных уязвимостей", - рассказал он.
По словам Эдуарда Тихомирова, такие сбои всегда конвертируются в конкретные задачи для снижения рисков. Он отметил, что подобные инциденты будут смещать выбор разработчиков в пользу суверенных платформ, прежде всего в госсекторе и КИИ, где требования регуляторов и так создают давление в эту сторону.
"GitHub останется важной площадкой для open source и обмена опытом между специалистами — и это ценно. Но рабочий код критичных систем должен лежать там, где его доступность гарантирована вне зависимости от того, что происходит на зарубежной стороне", - сказал он.
С ним отчасти согласился Александр Курач. Он отметил, что подобные сбои могут привести к задержкам в работе команд, особенно если разработчики завязаны на внешние репозитории или документацию. Это, как следствие, замедлит сборку, тестирование, обновление компонентов и работу с open source-проектами, а в долгосрочной перспективе такие ситуации усиливают тренд на технологическую автономность.
"Компании будут внимательнее оценивать зависимость от внешних платформ и чаще переносить критичные процессы разработки в собственный или доверенный контур. При этом полностью отказаться от GitHub вряд ли возможно и не всегда рационально, так как его ценность заключается не только в сервисе хранения кода, но и в масштабной open source-экосистеме", - рассказал он.
Сбой, по мнению Антона Прокофьева, приведет к подрыву репутации GitHub в глазах российского ИТ-сектора как стабильной платформы, а также к вынужденному росту использования VPN-сервисов. Он отметил, что многим разработчикам приходится использовать средства обхода для продолжения работы даже на разрешенных ресурсах.
"В долгосрочной перспективе есть риск отрыва российской разработки от глобального open source-сообщества, что может лишить софтверную индустрию open source-наработок и международной обратной связи. Не исключаю, что подобные ограничения могут коснуться и других иностранных платформ для разработчиков", - заметил он.
Для уменьшения ущерба от подобных инцидентов, по словам Антона Прокофьева, разработчикам важно убедиться, что проекты можно собрать и опубликовать вручную без привязки к GitHub, и что этот процесс описан в документации. Он порекомендовал регулярно создавать полные резервные копии репозиториев с сохранением истории изменений, а не только скачивать архив файлов.
"При этом важно не просто сохранить копию, но и проверить, что из нее можно запустить проект", - отметил он.
По словам Эдуарда Тихомирова, универсальной мерой является строительство критичных процессов на полностью контролируемой инфраструктуре, то есть переход на self-hosted-платформы, развернутые внутри периметра организации. Это освободит репозитории, CI/CD и реестры артефактов от зависимости от зарубежных провайдеров и от качества внешнего канала связи.
"Для компаний, которые пока не готовы полностью уйти с GitHub, разумный минимум — зеркалирование критичных репозиториев на суверенную платформу и настроенный резервный CI/CD-контур. Это не исключает сбой, но существенно сокращает время простоя", - сказал он.
