Исследователи Veracode сообщили о вредоносном пакете @acitons/artifact в экосистеме npm, который имитировал легитимный @actions/artifact и был нацелен на окружения GitHub Actions. Вскоре после публикации выяснилось, что речь шла не о реальной компрометации, а о строго контролируемых учениях Red Team GitHub, призванных проверить устойчивость внутренних процессов безопасности.
Как работала атака: typosquatting и вредоносный postinstall
Пакет был опубликован 29 октября 2025 года и быстро получил широкое распространение: 47 405 загрузок суммарно, из них 31 398 за последнюю неделю. Использовалась классическая техника typosquatting — подмена порядка букв в scope (@acitons вместо @actions), что эксплуатирует человеческие ошибки при наборе зависимостей.
По данным Veracode, вредоносную логику содержали шесть версий — 4.0.12–4.0.17. Они включали postinstall-хук, автоматически загружавший бинарь harness из уже удаленного GitHub-аккаунта. Этот компонент представлял собой обфусцированный shell-скрипт с «таймером»: если системная дата была 6 ноября 2025 года и позже, загрузка не выполнялась.
Далее скрипт запускал verify.js, который проверял наличие переменных среды GITHUB_*, характерных для GitHub Actions. При обнаружении целевого окружения происходила кража временных токенов GitHub Actions с их шифрованием и отправкой на поддомен app.github.dev. Дополнительно реализована фильтрация по владельцу репозитория: при несовпадении GITHUB_REPOSITORY_OWNER с организацией GitHub выполнение прекращалось, что указывает на таргетированный сценарий.
Учетная запись blakesdev, через которую публиковались версии, удаляла вредоносные релизы по мере расследования; публично доступной осталась «чистая» 4.0.10. Исследователи также зафиксировали схожий пакет 8jfiesaf83 (уже удален), который успели скачать 1 016 раз.
Почему это важно: риски для цепочки поставок ПО
Случай демонстрирует, насколько уязвимы цепочки поставок ПО к комбинации typosquatting и установочных скриптов. postinstall запускается автоматически в момент установки зависимости, что превращает любую опечатку в потенциальную точку входа. В контексте CI/CD это особенно критично: скомпрометированный пакет способен получить доступ к секретам пайплайна, артефактам сборки и временным токенам, используемым для операций с репозиториями.
Хотя GitHub подтвердил, что это были реалистичные учения, инцидент резонирует с реальными атаками на экосистемы открытого ПО и подчеркивает необходимость принципов минимально необходимых привилегий и строгого контроля исходного происхождения зависимостей в автоматизированных окружениях.
Позиция GitHub и дискуссия об этичности публичных учений
Представители GitHub заявили, что упражнения проводились под контролем, а «системы и данные GitHub ни в какой момент не были под угрозой». Тем не менее тот факт, что «учебный» пакет оказался в публичном npm и набрал почти 50 тысяч установок, поднимает вопросы границ допустимого при моделировании угроз и возможного внешнего воздействия на разработчиков, не связанных с тестируемой организацией.
Баланс между реализмом и риском требует прозрачных критериев: четкого геофенсинга и таргетинга, минимизации побочных эффектов для сторонних пользователей и оперативной ревокации артефактов учений, особенно если они размещаются в общедоступных реестрах.
Практические рекомендации по защите CI/CD и зависимостей
Базовые меры для разработчиков и DevOps-команд
1) Исключите опечатки и подмену scope. Внедрите внутренние реестры/зеркала и allowlist для namespaces; используйте code review и шаблоны для зависимостей в монорепозиториях.
2) Жестко фиксируйте версии. Применяйте lock-файлы (package-lock.json), установку через npm ci, периодический ревью зависимостей и отказ от автоматических мажорных апдейтов.
3) Ограничьте выполнение скриптов. По возможности отключайте lifecycle-скрипты (npm install —ignore-scripts) в CI, разрешая их точечно лишь там, где это действительно требуется.
4) Укрепите GitHub Actions. Снижайте права GITHUB_TOKEN до необходимого минимума, используйте environment protection rules, OIDC и политику на «запрещающие по умолчанию» секреты.
5) Включите сетевую сегментацию и мониторинг. Ограничьте исходящие соединения раннеров по allowlist, логируйте и алертуйте нетипичный трафик, внедряйте EDR/NSM в CI.
6) Прозрачность цепочки поставок. Формируйте SBOM (например, CycloneDX), внедряйте политику доверенного происхождения пакетов и проверку целостности артефактов.
История с @acitons/artifact — наглядное напоминание о хрупкости экосистем открытого ПО и важности дисциплины в управлении зависимостями. Пересмотрите политики безопасности ваших CI/CD, минимизируйте права токенов, ограничьте выполнение скриптов и внедрите строгие процессы верификации пакетов. Это не только снизит риск реальных атак на цепочку поставок, но и позволит безболезненно переживать даже самые «реалистичные» учения.
