Как защититься от repojacking на GitHub

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

Важно: реподжекинг чаще всего эксплуатирует человеческий фактор (пропущенное обновление зависимости, незарезервированное старое имя). Поэтому защита — это сочетание технических мер и процедур.

Что такое repojacking

Repojacking — это эксплойт, который происходит после изменения имени владельца репозитория на GitHub. Старая комбинация username/repository становится доступной для регистрации. Злоумышленник может: зарегистрировать старое имя пользователя, создать репозиторий с тем же именем и поместить в него код, который будут загружать как зависимость автоматические сборки и приложения.

Краткие типы риска:

• Надёжность приложений: приложение, которое обращается к репозиторию по прямой ссылке, если владелец переименовал репозиторий, может начать получать код от злоумышленника.
• Риск для разрабатываемых продуктов: если вы указываете внешние репозитории как зависимости и не отслеживаете перенаправления/изменения, ваша сборка может быть скомпрометирована.

Реподжекинг сам по себе не всегда приводит к немедленной массовой атаке, но он является удобным механизмом для supply chain-атак: встраивание вредоносного кода в зависимость даёт доступ к большому числу приложений.

Как минимизировать риск repojacking

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

Создавайте приватные зеркала репозиториев

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

Пример команд (копирование и зеркалирование репозитория):

# Склонировать репозиторий в «bare» формат
git clone --bare https://github.com/username/repo.git

# Запушить зеркало в приватный репозиторий (HTTPS или SSH в зависимости от настроек)
git push --mirror git@github.com:your-org/private-repo.git

Пояснение: bare-клон хранит все ветки и теги; push –mirror переносит все ссылки. После этого у вас есть приватный источник, который вы контролируете.

Тщательно отслеживайте зависимости

Периодически (например, ежеквартально или чаще для критичных проектов) проверяйте список внешних зависимостей. Для каждой зависимости фиксируйте:

• источник (URL и владелец),
• используемую версию/COMMIT или тег,
• кто ответственен за обновление.

Мини‑методология аудита зависимостей:

1. Экспортировать список зависимостей (package manager, go.mod, requirements.txt, submodule list).
2. Проверить доступность и владельца каждого репозитория.
3. Сверить версии/COMMIT с опубликованными релизами.
4. Задокументировать и пометить для обновления те, где владелец изменил имя или репозиторий удалён.

Оставляйте старые имена или резервируйте их

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

Важно: резервирование имени — административная нагрузка, но часто эффективная.

Применяйте безопасные способы доступа

Используйте SSH-ключи для доступа к приватным зеркалам, настройте ограниченные токены доступа и минимальные привилегии для CI/CD. Это снижает риск, что злоумышленник получит запись в вашем CI и начнёт подтягивать вредоносные пакеты.

Практический план действий для команд

Ниже — краткий playbook, который можно внедрить сразу.

1. Инвентаризация: собрать все внешние зависимости и владельцев.
2. Рейтинг риска: пометить зависимости как «критичные», «важные», «низкий риск».
3. Для критичных — создать приватные зеркала и переключить CI на них.
4. Для всех — настроить мониторинг изменений владельцев (watch или уведомление).
5. При смене имени — незамедлительно создавать резервную учётную запись для старого имени.
6. Проводить ревью зависимостей перед релизом.

Короткий SOP для разработчика при изменении имени аккаунта:

• Уведомить команду и CI/Release-менеджера.
• Создать резервную учётную запись и зарегистрировать старое имя.
• Проверить все внешние зависимости на наличие ссылок на старый namespace.
• При необходимости сделать приватные зеркала и обновить CI.

Роли и контрольные списки

Разработчик:

• Проверил список зависимостей перед релизом.
• Закрепил версию/COMMIT в манифестах зависимостей.
• Сообщил о смене имени в командный чат.

Секьюрити-инженер:

• Настроил мониторинг доступности и владельцев внешних репозиториев.
• Провёл аудит прав доступа CI/CD.
• Настроил уведомления о новых репозиториях с критичными названиями.

Менеджер релиза:

• Проверил, что все критичные зависимости имеют приватные зеркала или зафиксированные артефакты.
• Подтвердил план отката на случай компрометации зависимости.

Матрица рисков и смягчающие меры

Когда эти меры не сработают

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

Краткая глоссарий

• Repojacking — захват освобождённого имени репозитория с целью подмены кода.
• Зеркало (mirror) — приватная копия репозитория, которая служит надежным источником кода.
• Фиксированная версия — явная привязка зависимости к конкретному тегу или коммиту.

Критерии приёмки

• Все критичные зависимости имеют приватные зеркала или зафиксированные артефакты.
• Команда уведомлена и имеет SOP на случай смены имени аккаунта.
• Мониторинг внешних репозиториев настроен и выдает оповещения о смене владельца.

Итог

Repojacking — реализуемая, но управляемая угроза. Комбинация простых технических мер (приватные зеркала, фиксация версий) и операционных процедур (аудиты зависимостей, резервирование имён, SOP) существенно снижает риск. Внедрите предложенный playbook и контрольные списки, чтобы минимизировать вероятность compromise в цепочке поставок.

Короткий чек-лист для начала:

• Собрать инвентарь зависимостей.
• Создать приватные зеркала для 3–5 критичных репозиториев.
• Настроить уведомления о смене владельцев внешних репозиториев.
• Опубликовать в командном репозитории SOP при смене имён.