У CrowdSec утащили код из 170 приватных GitHub-репозиториев

Что произошло, почему это важно и что взять в работу.

Утечка через не отозванный OAuth-токен уволенного сотрудника — повод для SMB провести ревизию доступов к репозиториям и отзывать токены в день увольнения.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Живой токен после увольнения

Короткая версия. CrowdSec признала: злоумышленник выкачал исходный код примерно из 170 приватных репозиториев на GitHub. Не через взлом платформы, не через уязвимость в зависимостях. Через OAuth-токен бывшего сотрудника, который не отозвали вовремя. Компания сама описала вектор — и это уже больше, чем обычно достаётся из публичных разъяснений по инцидентам.

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

Именно механика здесь и ценна. Потому что она воспроизводится в любой компании, где есть приватные репозитории, наём и увольнение. Масштаб у CrowdSec — 170 репозиториев. Масштаб у типичной российской SMB — пять, двадцать, максимум сотня. Разница в объёме, не в природе дырки.

Компания признала, что злоумышленник скачал код примерно из 170 приватных GitHub-репозиториев. По версии CrowdSec, доступ получили через OAuth-токен бывшего сотрудника, который не успели вовремя отозвать после увольнения.

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

Как токен переживает сотрудника

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

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

Дальше срабатывает накопительный эффект. Человек за годы работы оставил за собой не один токен. Классический personal access token без срока действия для скрипта выгрузки метрик. OAuth-разрешение мобильному клиенту. SSH-ключ на личном ноутбуке. Deploy key, привязанный к конкретному репозиторию. Токен, который когда-то выдали ради разовой задачи и не удалили, потому что «работает и не мешает». Каждый такой доступ — отдельная дверь. Увольнение закрывает одну, максимум две.

Отсюда и берётся «не успели вовремя». Не потому что кто-то ленивый, а потому что инвентаря этих дверей ни у кого нет. Пока нет инвентаря — нет и процедуры, которую можно выполнить в день увольнения.

Что утекает вместе с кодом

Соблазн отмахнуться: «увели исходники, ну и что, у нас не Google». Опасная логика. На приватных репозиториях обычно лежит не только код продукта.

Там конфиги окружений. Схема базы. Имена внутренних сервисов и адреса стендов. Файлы CI, в которых видно, откуда деплоится прод и какие шаги для этого нужны. Иногда — историю коммитов, где годами оседают забытые ключи и пароли, которые вычистили из свежего кода, но не из глубины истории. Для атакующего это карта системы, а не набор текстовых файлов. С картой проще искать вход, который не закроют после инцидента.

Отдельный слой — репутационный и договорной. Если код уходит партнёрам или заказчикам по контракту, утечка запускает разговор не про безопасность, а про обязательства. У CrowdSec, судя по публичности признания, есть на это ресурс и юристы. У SMB такого ресурса обычно нет — есть один руководитель, который одновременно разбирается с клиентом, техникой и кадрами.

Таблица ревизии: что искать у себя

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

Минимальный набор на день увольнения

1. Отзыв доступов как кадровое действие. Не задача для разработчика «когда будет время», а пункт в чек-листе увольнения рядом с выдачей трудовой. Пока это живёт в голове тимлида, оно будет просрочено.
2. Список владельцев токенов. Выпишите, у кого есть OAuth-разрешения и personal access tokens к вашей организации. Если список собирается дольше часа — у вас нет ответа на вопрос «кто может читать наш код».
3. Срок жизни вместо бессрочности. Токен с датой истечения — это автоматическое закрытие двери, которое не зависит от чьей-то памяти.
4. Разделение людей и сервисов. Скрипты и CI должны ходить под отдельными машинными учётками, а не под токеном конкретного инженера. Тогда увольнение не роняет сборку и не оставляет живых ключей.
5. Ротация при уходе. Если человек мог видеть секреты, они считаются потенциально скомпрометированными. Не потому что он злоумышленник, а потому что вы не контролируете, где эти секреты осели.
6. Логи и алерты. Массовая выгрузка репозиториев — событие, которое должно быть заметно. Если о факте скачивания вы узнаёте от третьей стороны, детект у вас отсутствует.

Это скучно. Никакого вау-эффекта, никакого внедрения платформы за миллион. Ровно поэтому такие вещи и остаются невыполненными до инцидента.

Утечка через токен уволенного сотрудника — это не про слабую защиту GitHub. Это про отсутствие списка, в котором перечислено, у кого есть ключи. Нет списка — нет и увольнения в юридическом смысле.

Где здесь перегиб

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

Второе. Провести ревизию доступов один раз недостаточно. Она зарастает за месяц-два: новые люди, новые интеграции, новые «временные» токены для разовой задачи. Без регулярного пересмотра вы получите ту же картину, что и до ревизии, только с чувством выполненного долга.

Третье. Автоматизация через SSO с синхронизацией учёток закрывает большую часть проблемы, но не всю. Токены, выданные приложениям и скриптам, живут вне пользовательских сессий, и их синхронизация не касается. Это отдельный контур, который надо вести руками или отдельным инструментом.

Вердикт

История CrowdSec — это не экзотика уровня корпорации. Это стандартный сценарий: доступ живёт дольше, чем трудовой договор. У большой компании риск измеряется в 170 репозиториях, у SMB — в одном, где лежит конфиг прода.

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