Рост числа вредоносных репозиториев на GitHub: что нужно знать командам разработки

Почему GitHub стал главной мишенью для атак на цепочки поставок

Разработчик клонирует репозиторий, который выглядит точь-в-точь как популярная библиотека с открытым исходным кодом. README оформлен безупречно, код выглядит рабочим, а количество звёзд кажется вполне правдоподобным. Спустя несколько недель из CI/CD-пайплайна начинают утекать учётные данные. Репозиторий оказался тщательно сделанной подделкой.

Этот сценарий уже перестал быть редкостью. GitHub, будучи крупнейшей платформой для программного обеспечения с открытым исходным кодом, стал постоянной мишенью для злоумышленников, публикующих вредоносные репозитории с целью компрометации сред разработки, кражи учётных данных и внедрения бэкдоров в продакшн-системы. Для любого бизнеса, который зависит от open-source кода — а это практически каждая софтверная компания — это прямой операционный риск.

Как злоумышленники эксплуатируют модель доверия GitHub

Тайпсквоттинг и репозитории-копии

Самый простой приём одновременно является и самым эффективным. Злоумышленники создают репозитории с названиями, почти идентичными популярным библиотекам — заменяя букву, добавляя дефис или используя похожее по звучанию имя. Согласно анализу Snyk, такие вредоносные репозитории на GitHub представляют угрозу не только отдельным разработчикам, но и целым организациям. При клонировании или интеграции в другие проекты вредоносное ПО распространяется, что ведёт к потенциальным утечкам данных или компрометации систем.

Проще говоря: если разработчик наберёт react-routter вместо react-router и найдёт репозиторий, который выглядит легитимно, одно неосторожное клонирование может скомпрометировать весь сборочный пайплайн.

RepoJacking: захват заброшенных пространств имён

Более изощрённая атака предполагает захват неиспользуемых имён пользователей или организаций на GitHub и повторную публикацию троянизированных версий ранее легитимных репозиториев. Исследование команды AquaSec «Nautilus» показало, что примерно 2,95% проанализированных репозиториев могут быть уязвимы к RepoJacking — в масштабах GitHub это ставит под потенциальную угрозу около 9 миллионов проектов.

Это важно, потому что существующие проекты, ссылающиеся на URL исходного репозитория, после захвата будут незаметно загружать код из версии злоумышленника. Обновления подмодулей, модули Terraform, CI/CD-воркфлоу — любая автоматизированная ссылка становится потенциальным вектором заражения.

Атаки невидимым кодом

Последняя эволюция атак особенно опасна. Исследователи Aikido Security сообщили в марте 2026 года, что обнаружили 151 вредоносный пакет, загруженный на GitHub за одну неделю (3–9 марта), с использованием символов Unicode, невидимых для человеческого глаза, редакторов и интерфейсов ревью кода. Видимые части этих пакетов были высокого качества. Вредоносная нагрузка — стилеры учётных данных, сборщики токенов — была закодирована символами, которые просто не отображаются на экране.

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

Ущерб для бизнеса — конкретный, а не теоретический

Инцидент с tj-actions/changed-files

В одной из самых значимых атак на цепочку поставок, зарегистрированной как CVE-2025-30066, злоумышленники модифицировали GitHub Action, используемый более чем в 23 000 репозиториев. Внедрённый код — функция на Node.js в кодировке base64 — загружал вредоносный Python-скрипт, который сканировал память GitHub Runner в поисках секретов: паролей и API-ключей. Исследователи из Wiz выявили десятки затронутых репозиториев, принадлежащих крупным организациям.

Реальные цифры: 23 000 скомпрометированных репозиториев. Один взломанный Action. Секреты из публичных репозиториев оказались в общедоступных логах воркфлоу.

Кампания Shai-Hulud

Как описано в блоге безопасности самого GitHub, многоволновая вредоносная кампания Shai-Hulud распространялась через скомпрометированные npm-пакеты, собирая локальные системные токены при установке. Украденные токены затем использовались для дальнейшего распространения — причём некоторые токены хранились неделями или месяцами, прежде чем были задействованы в повторных атаках. Один скомпрометированный аккаунт мейнтейнера мог привести к заражению сотен пакетов.

Расширяющаяся поверхность атаки

Исследование OX Security, опубликованное Dark Reading, выявило 10 различных векторов риска на протяжении жизненного цикла разработки ПО, где ссылки на GitHub создают точки входа для вредоносного кода. Цифры говорят сами за себя:

• Инфраструктура как код: примерно 114 000 файлов Terraform и 13 000 файлов terragrunt.hcl ссылаются на модули GitHub, многие из которых используют изменяемые ссылки вроде ?ref=main
• Управление конфигурацией: около 3 000 файлов Ansible requirements, 5 000 инсталляций Grafana и 5 000 конфигураций Logstash загружают компоненты напрямую с GitHub
• Helm-чарты: непроверенные чарты с хуками, загруженными из GitHub, могут развёртывать вредоносные ресурсы с правами уровня кластера

Что это значит для вашего проекта: поверхность атаки выходит далеко за рамки npm install. Любая автоматизированная ссылка на URL GitHub — в Terraform, Ansible, Docker, Helm или конфигурациях CI/CD — является потенциальным вектором.

Почему злоумышленники переходят от реестров пакетов к репозиториям

Согласно исследованию ReversingLabs, освещённому Dark Reading, количество атак с использованием вредоносных пакетов в реестрах вроде npm и PyPI фактически снижается. Реестры пакетов серьёзно инвестировали в автоматическое сканирование, обнаружение вредоносного ПО и безопасность аккаунтов. Результат: злоумышленники переключаются на репозитории GitHub, где средства защиты менее зрелые.

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

Ключевой вывод для бизнеса: усиление защиты реестров пакетов вытолкнуло злоумышленников выше по цепочке поставок. Проблема не уменьшилась — она переместилась.

Практические меры защиты, которые действительно работают

1. Зафиксируйте всё через неизменяемые ссылки

Никогда не ссылайтесь на контент GitHub, используя изменяемые имена веток вроде main или master. Привязывайте зависимости, подмодули, Actions и модули IaC к конкретным SHA коммитов.

Для GitHub Actions это означает использование: uses: actions/checkout@a1b2c3d4e5f6 (SHA коммита) вместо: uses: actions/checkout@v4 (изменяемый тег)

2. Автоматизируйте сканирование зависимостей в CI/CD

Как рекомендуют специалисты по безопасности цепочек поставок, каждый pull request, изменяющий зависимости, должен запускать автоматические проверки:

• Валидация целостности lock-файла (используйте флаги --frozen-lockfile или --immutable)
• Перекрёстная проверка по GitHub Advisory Database и фиду OSSF malicious packages
• Статический анализ на подозрительные паттерны: тайпсквоттинг или нестандартные установочные скрипты

Такие инструменты, как GuardDog от DataDog и GitHub Action RoguePkg, позволяют автоматизировать обнаружение вредоносных пакетов непосредственно в воркфлоу pull request'ов, блокируя мёрж при обнаружении угроз.

3. Контролируйте время обновлений

Вредоносные пакеты наиболее опасны сразу после публикации — до того, как сообщество обнаружит и сообщит о них. Настройте Dependabot или Renovate с периодом ожидания, чтобы автоматические обновления не подтягивали только что опубликованные (и потенциально скомпрометированные) версии мгновенно.

4. Проверяйте подлинность репозитория перед клонированием

Перед интеграцией любого репозитория с GitHub:

• Проверьте возраст и историю аккаунта организации или пользователя
• Убедитесь, что URL репозитория точно совпадает с официальной документацией
• Обратите внимание на недавние смены владельца (признак возможного RepoJacking)
• Сравните содержимое репозитория с заведомо корректными версиями, используя такие инструменты, как сравнение AST

5. Защитите аккаунты мейнтейнеров

В рекомендациях GitHub по итогам кампании Shai-Hulud особо подчёркивалась безопасность аккаунтов мейнтейнеров: включите двухфакторную аутентификацию с passkey, используйте детализированные персональные токены доступа с минимальными правами и регулярно проверяйте, какие токены имеют доступ к репозиториям.

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

1. Привяжите все внешние ссылки к SHA коммитов — Actions, подмодули, модули Terraform, Helm-чарты
2. Запускайте автоматическое сканирование на вредоносное ПО при каждом PR, затрагивающем файлы зависимостей
3. Обеспечьте целостность lock-файлов в CI с помощью --frozen-lockfile
4. Задержите автоматическое обновление зависимостей на 48–72 часа
5. Требуйте 2FA на основе passkey для всех аккаунтов, публикующих пакеты или поддерживающих репозитории

Честная оценка

Атаки на цепочки поставок через репозитории GitHub никуда не денутся. Команда безопасности GitHub признаёт, что злоумышленники «быстро учатся, нацеливаются на рабочие процессы мейнтейнеров и эксплуатируют границы доверия в пайплайнах публикации». Как отмечает Snyk, этот тип атак не ограничивается GitHub — любой репозиторий исходного кода, где можно делиться и копировать код, является потенциальным вектором.

Честная оценка: решение не в том, чтобы отказаться от open source. Это означало бы потерю главного преимущества современной разработки. Решение — относиться к каждой внешней зависимости — будь то из npm, PyPI или репозитория GitHub — как к недоверенным входным данным до момента их верификации.

Ключевой вывод для бизнеса: затраты на внедрение автоматического сканирования зависимостей, фиксации ссылок и обеспечения целостности lock-файлов измеряются часами настройки DevOps. Затраты на компрометацию цепочки поставок — утечку учётных данных, взлом продакшн-систем, реагирование на инциденты — измеряются неделями и значительным финансовым ущербом. Арифметика проста.

Часто задаваемые вопросы

Как разработчики могут отличить легитимные репозитории от убедительных подделок, имитирующих популярные проекты?

Сверяйте URL репозитория с официальной документацией или веб-сайтом проекта. Проверяйте возраст аккаунта, историю контрибуций и наличие верификации организации на GitHub. Подделки часто имеют недавнюю дату создания, скудную историю коммитов и отсутствие бейджей CI/CD-статуса от известных сервисов.

Могут ли злоумышленники успешно захватить заброшенные аккаунты и организации GitHub для публикации троянизированных версий ранее легитимных проектов?

Да. Исследование AquaSec показало, что примерно 2,95% проанализированных репозиториев могут быть уязвимы к RepoJacking, при котором злоумышленники регистрируют неиспользуемые имена пользователей и повторно публикуют троянизированный код. GitHub реализовал некоторые меры защиты от этого, но риск остаётся значительным для проектов, ссылающихся на старые URL.

Насколько эффективны текущие сигналы доверия — количество звёзд, форков и история коммитов — для выявления вредоносных репозиториев?

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

Какие техники используют злоумышленники, чтобы поддерживать активность вредоносных репозиториев и их видимость в поисковой выдаче GitHub?

Злоумышленники применяют SEO-техники: популярные ключевые слова в названиях и описаниях репозиториев, накрученные звёзды и форки, частые коммиты для создания видимости активности и качественные README-файлы. Новейшая эволюция использует невидимые символы Unicode для сокрытия вредоносной нагрузки от ревью кода, благодаря чему видимая часть кода выглядит чистой и функциональной.