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

Если вы заподозрили, что репозиторий подменён — то есть код, история коммитов или настройки проекта изменены не теми людьми, которым вы доверяете, — главная задача первых часов: остановить распространение подозрительного кода и зафиксировать состояние системы до того, как кто-то «почистит следы». Не пытайтесь сразу всё исправить руками: сначала изолируйте, потом проверяйте, потом восстанавливайте. Порядок именно такой, потому что поспешные правки затирают улики и мешают понять масштаб проблемы.

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

Что считается подменой репозитория

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

• Компрометация учётной записи: злоумышленник получил доступ к аккаунту разработчика с правами записи и внёс изменения легитимным путём.
• Подмена удалённого адреса: у части команды remote в git указывает на поддельный сервер, который перехватывает коммиты или раздаёт изменённый код.
• Вредоносный пакет или CI-скрипт: сам репозиторий цел, но сборка подтягивает изменённую зависимость или выполняет внедрённый скрипт.
• Перехват трафика: клонирование идёт через незащищённое соединение или поддельный DNS, и разработчик получает модифицированный код.
• Компрометация самого хостинга: редкий, но самый тяжёлый случай, когда под сомнением оказывается вся платформа.

Различать эти сценарии важно, потому что действия при скомпрометированном аккаунте (отзыв токенов, смена паролей) сильно отличаются от действий при подмене зависимости (аудит lock-файлов и артефактов сборки).

Признаки, которые должны насторожить

Типичные сигналы, при которых стоит действовать по протоколу инцидента, а не «разбираться на месте»:

• в истории появились коммиты, которых никто из команды не помнит, особенно с правками в CI-конфигурации, скриптах сборки или файлах зависимостей;
• хеш известного коммита изменился — например, после pull ветка «перестроилась», хотя никто не делал rebase или force push;
• коллеги получают странные сообщения от вашего имени или видят ваши активные сессии там, где вы не работали;
• CI начал публиковать артефакты, которые не собирались локально, или сборка выполняет неожиданные сетевые запросы;
• антивирус, EDR или мониторинг ругаются на процессы, запущенные из каталогов сборки;
• адрес удалённого репозитория отличается хотя бы одним символом от привычного;
• партнёр или клиент сообщает, что получил от вас версию продукта с поведением, которого быть не должно.

Один подозрительный признак — повод проверить. Два и более — повод считать инцидент подтверждённым до окончания разбора.

Первые часы: порядок действий

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

Шаг 1. Остановите распространение

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

Шаг 2. Зафиксируйте текущее состояние

Сделайте снимки всего, что может понадобиться для анализа:

1. полная копия репозитория со всеми ветками, тегами и reflog;
2. логи хостинга: аудит событий доступа, история force push, изменения настроек, список активных ключей и токенов;
3. логи CI/CD последних сборок и деплоев;
4. образы и артефакты, опубликованные за последние дни;
5. скриншоты или экспорт настроек репозитория: вебхуки, deploy keys, права участников, интеграции.

Храните копии вне скомпрометированной инфраструктуры. Вебхуки и deploy keys — частый канал закрепления атакующего: их проверяют не все, а зря.

Шаг 3. Отзовите доступы

Смените пароли и принудительно завершите все активные сессии у всех, кто имел права записи. Перевыпустите персональные токены доступа, SSH-ключи, секреты CI, пароли от реестров пакетов. Проверьте, не добавлены ли новые участники, ключи или OAuth-приложения. Если используется двухфакторная аутентификация — убедитесь, что она включена у всех, а не только у администраторов.

Шаг 4. Определите точку отсчёта

Ключевой вопрос расследования: какой последний коммит можно считать достоверным? Сравните локальные копии у разных членов команды: если у большинства хеш последнего «нормального» коммита совпадает, а в удалённом репозитории история другая — вы нашли момент подмены. Полезно свериться с внешними свидетельствами: упоминаниями хешей в задачах трекера, code review, сообщениях в чате, подписанных тегах.

Шаг 5. Проанализируйте подозрительные изменения

Диффы между достоверной точкой и текущим состоянием изучайте в первую очередь в этих местах:

• конфигурация CI/CD — классическое место для внедрения выполнения посторонних команд;
• файлы блокировок зависимостей (lock-файлы) — изменение версии или источника пакета;
• скрипты установки, сборки и публикации;
• код работы с секретами, сетью, файловой системой;
• изменения в правах, вебхуках и интеграциях на стороне хостинга.

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

Как проверить целостность репозитория

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

Сверка истории коммитов

Команда вида просмотра лога с датами и авторами по всем веткам позволяет заметить «лишние» коммиты. Обращайте внимание на:

• коммиты с авторством известных людей, но в необычное время или с нетипичным содержанием;
• расхождения между автором и подписью коммиттера;
• коммиты без прохождения review, если в проекте принято обязательное ревью.

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

Проверка удалённых адресов и транспорта

Убедитесь, что remote во всех рабочих копиях указывает на правильный хост, а соединение защищено. Поддельный домен часто отличается одной буквой или другим доменом верхнего уровня. Если есть основания подозревать DNS-подмену, сверьте разрешение имени через независимый резолвер и сравните отпечаток сертификата сервера с ожидаемым.

Аудит зависимостей и артефактов

Подмена часто происходит не в самом репозитории, а в поставке. Проверьте:

• совпадают ли хеши установленных зависимостей с зафиксированными в lock-файле;
• не появились ли в дереве зависимостей пакеты с опечатанными именами;
• совпадает ли хеш опубликованного артефакта с результатом сборки из достоверного коммита;
• нет ли в логах CI загрузки скриптов с посторонних адресов.

Сравнение с эталонной копией

Если у организации есть зеркала, бэкапы или офлайн-копии репозитория, дифф с ними быстро покажет объём изменений. Именно поэтому регулярное резервное копирование репозиториев — часть безопасности, а не только отказоустойчивости.

Восстановление после подтверждённой подмены

Когда масштаб понятен, действуйте в таком порядке:

1. Откатите удалённый репозиторий к последней достоверной точке. Force push допустим здесь осознанно и с предварительным уведомлением команды — в отличие от обычной работы.
2. Заново настройте защиту веток: запрет прямых пушей, обязательное ревью, ограничения на изменение CI-конфигурации.
3. Пересоберите все артефакты из чистого окружения на основе восстановленной истории и опубликуйте заново. Старые артефакты считайте скомпрометированными, даже если анализ ничего не нашёл, — стоимость пересборки почти всегда ниже стоимости пропущенного бэкдора.
4. Уведомите потребителей: пользователей библиотеки, клиентов, партнёров. Честное сообщение с версиями, которых касается проблема, и инструкцией по обновлению снижает ущерб сильнее, чем молчание.
5. Проведите разбор: как произошёл доступ, почему подмена не была замечена сразу, какие контрольные точки добавить.

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

Профилактика: что снижает риск повторения

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

• Подпись коммитов и тегов с политикой проверки подписей на критичных ветках.
• Жёсткая защита веток: запрет force push, обязательное ревью, отдельный протокол для изменений CI-конфигурации.
• Минимальные права: права записи только у тех, кому они нужны сейчас; регулярный аудит участников, ключей и OAuth-приложений.
• Фиксация зависимостей через lock-файлы и проверка хешей, желательно с внутренним прокси-реестром пакетов.
• Детерминированная сборка из чистых окружений, чтобы артефакт можно было воспроизвести и сверить.
• Мониторинг аудита хостинга с алертами на force push, изменение настроек и добавление ключей.
• Регулярные бэкапы репозиториев в независимой инфраструктуре.
• Фишинг-устойчивая аутентификация: аппаратные ключи или устойчивые к перехвату методы вместо одних лишь SMS-кодов.

Типичные ошибки при реагировании

Ошибка	Чем опасна	Как правильно
Сразу удалить или пересоздать репозиторий	Уничтожаются доказательства, невозможно определить масштаб и источник	Сначала снять полные копии и логи, потом менять инфраструктуру
Тихо откатить код без уведомления команды	Часть разработчиков продолжает работать от скомпрометированного состояния	Объявить инцидент явно, назначить координатора и канал связи
Проверять подозрительный код на рабочей машине	Расширение компрометации на личные и корпоративные данные	Изолированное окружение без доступа к внутренним системам
Сменить только пароль основного аккаунта	Токены, SSH-ключи и секреты CI остаются у атакующего	Ротация всех типов креденшелов, включая машинные
Не публиковать старые артефакты повторно, но и не предупреждать пользователей	Пользователи продолжают использовать потенциально вредоносные версии	Явное уведомление с перечнем затронутых версий и инструкцией
Считать инцидент закрытым после отката	Не устранённая причина приводит к повторению	Разбор причин и внедрение контрольных точек до закрытия инцидента

Сценарии: если условия такие — действуйте так

• Подмена замечена до публикации релиза. Самый лёгкий случай: заморозьте пайплайн, проведите анализ, откатите историю, пересоберите. Пользователи не затронуты.
• Артефакты уже опубликованы. Снимите их с раздачи, выпустите исправленную версию с новым номером, уведомите пользователей и, если пакет публичный, опубликуйте предупреждение в каналах экосистемы.
• Скомпрометирован аккаунт администратора. Действуйте шире: аудит всех репозиториев организации, а не одного, отзыв всех выданных за период инцидента токенов, проверка настроек SSO.
• Есть признаки компрометации машин разработчиков. Ротации доступов недостаточно: нужна проверка конечных точек силами ИБ, иначе атакующий вернётся через тот же вход.
• Инцидент затрагивает клиентов или персональные данные. Подключайте юридическую функцию и руководство: появляются обязательства по уведомлению, которые нельзя решать силами только технической команды.

Частые вопросы

Можно ли просто удалить подозрительные коммиты и продолжить работу?

Технически да, но это худший вариант. Без фиксации состояния и анализа вы не знаете, был ли изменён ещё что-то: секреты, настройки, зависимости. Минимум — сохраните копию до любых правок и поймите, каким путём изменения попали в репозиторий.

Как понять, какой коммит последний «чистый»?

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

Обязательно ли уведомлять пользователей, если проблема была только внутри команды?

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

Помогает ли двухфакторная аутентификация от таких инцидентов?

Она существенно усложняет захват аккаунта, но не защищает от всех сценариев: украденный сессийный cookie, вредоносное OAuth-приложение или скомпрометированная машина разработчика обходят её. Поэтому 2FA — необходимое, но не достаточное условие.

Кто должен координировать реагирование?

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

С чего начать прямо сейчас

Главный принцип: изолировать — зафиксировать — проанализировать — восстановить, строго в этом порядке. Сильнее всего на исход влияют два фактора: скорость остановки распространения и наличие снимков состояния до начала «исправлений».

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

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