Проблема
Когда атакующий получает токены разработчика или доступ к registry-публикации, incident response нельзя сводить к удалению одного пакета. Нужно считать скомпрометированной всю цепочку доверия: GitHub/GitLab, npm/PyPI, CI secrets, облачные ключи, developer devices и интеграции, которым раньше автоматически доверяли.
Почему это важно
Supply-chain инцидент опасен своей скоростью. Один скомпрометированный maintainer, pipeline или package token может дать доступ к сотням downstream-проектов. Защитная команда должна действовать как диспетчер доверия: быстро понять, какие ключи могли утечь, какие релизы были собраны в рискованном окне и какие потребители должны получить предупреждение.
Что проверять руками
Нужно сверить список токенов с фактическим использованием, убрать бессрочные ключи, включить provenance/signing, ограничить publish-права, проверить CI logs на необычные job-переменные и отдельно посмотреть workstation-разработчиков, где могли храниться browser/session tokens.
Решение
Самый полезный артефакт после такого инцидента — не список IoC, а таблица отзыва доверия: какой токен, кто владелец, где использовался, когда отозван, какой сервис пересобран и как доказано, что новый релиз собран из чистого состояния.
Defensive checklist
- Заменить long-lived package tokens на scoped и короткоживущие credentials.
- Запретить публикацию пакетов без MFA и подтверждённого maintainer-профиля.
- Добавить SBOM/provenance для релизов и хранить build attestation.
- Проверять CI на секреты не только в коде, но и в переменных окружения.
- После инцидента пересобирать релизы из чистого runner-окружения.
Безопасная матрица отзыва токенов
token_owner,system,scope,rotated_at,evidence
release-bot,npm,publish:package,2026-09-21,audit-log-id-1842
ci-runner,cloud,deploy:staging,2026-09-21,secret-version-37
maintainer-a,github,repo:write,2026-09-21,session-revoked