GitHub Actions Credential Revocation Checklist
Чеклист, что именно нужно отозвать и перевыпустить после подозрения на компрометацию CI/CD-пайплайна — от npm-токенов до облачных ключей.
Отметьте пункты по мере выполнения. Список основан на категориях credentials, которые реально воровала малварь в атаках на npm-экосистему 2026 года (Shai-Hulud, AsyncAPI/Miasma). Ничего не отправляется на сервер — состояние живёт только в этой вкладке.
Как это работает
После подтверждённой или подозреваемой компрометации CI/CD-пайплайна счёт идёт на часы: атака на AsyncAPI в июле 2026 показала, что от первой вредоносной публикации до её обнаружения исследователями прошло всего 30 минут, а до полного снятия с реестра — около 4 часов. Но обнаружение и снятие вредоносной версии с npm не значит, что инцидент закрыт — все credentials, к которым потенциально имел доступ скомпрометированный пайплайн, нужно считать скомпрометированными и отзывать, даже если прямых доказательств их кражи нет.
Список пунктов в этом чеклисте основан на категориях данных, которые реально воровала малварь в атаках 2026 года (Shai-Hulud, Miasma RAT в кампании на AsyncAPI): пароли из браузера, SSH-ключи, npm-токены, GitHub CLI токены, AWS-креды, криптокошельки. Чеклист не проверяет ничего автоматически — это структурированный список для ручного прохождения во время инцидента или постмортема, когда легко упустить один из менее очевидных пунктов (например, ротацию SSH-ключа в отдельном репозитории, который использовал ту же скомпрометированную ветку, но не был первым обнаруженным).
Состояние чеклиста живёт только в этой вкладке браузера и нигде не сохраняется — специально, потому что список отмеченных/неотмеченных пунктов во время реального инцидента является чувствительной информацией. Кнопка «Экспортировать как markdown» формирует текстовый чеклист с отметками для вставки в тикет, Slack-канал инцидента или итоговый постмортем-документ.
Частые вопросы
Нужно ли проходить весь список при любом подозрении на компрометацию?
Список — отправная точка, а не строгий протокол. Объём зависит от того, что именно было скомпрометировано: если затронут только npm-токен одного пакета, разделы про облачные провайдеры и локальные машины разработчиков могут быть неприменимы. Но лучше явно отметить пункт как неприменимый в экспорте, чем пропустить его молча.
Почему в списке отдельно есть branch protection на всех ветках?
Потому что классическая практика защищать только main/master оставляет открытыми pre-production ветки (next, staging, alpha и подобные), из которых тоже возможна публикация через CI/CD — именно так была скомпрометирована AsyncAPI в июле 2026, атакующие получили push-доступ именно к незащищённой ветке next, а не к main.
Что делать, если непонятно, какие именно credentials были в зоне риска?
Правило по умолчанию — считать скомпрометированным всё, к чему потенциально имел доступ затронутый пайплайн или аккаунт, а не только то, что точно было украдено (это принцип, известный как assume breach). Для более точной оценки, какие конкретно секреты пересекались с затронутыми конфигами, можно свериться с нашим Post-Compromise Secret Exposure Scope Estimator.