Mini Shai-Hulud: граница доверия в supply chain#
Mini Shai-Hulud показывает предел безопасности цепочки поставок: криптографическая provenance может оставаться валидной, пока сборка уже скомпрометирована. Подписи не подделывались. Атакующие использовали легитимные CI/CD пути, чтобы извлечь креденшелы, отравить общий build state и опубликовать вредоносные npm пакеты под реальными идентичностями.
Что произошло в атаке Mini Shai-Hulud#
11 мая 2026 атакующие скомпрометировали 84 npm артефакта в 42 пакетах, позже распространение превысило 170 пакетов. Цепочка включала: неправильную конфигурацию GitHub Actions, где код из pull request из fork выполнялся в доверенном контексте; отравление shared cache между workflow; извлечение OIDC токена из памяти runner во время выполнения. Итог — публикация в npm через легитимную инфраструктуру с валидными SLSA Build Level 3 аттестациями.
Эти аттестации не были подделаны. Они корректно отражали то, что наблюдала скомпрометированная система сборки. SLSA описывает результат сборки, а не доверенность окружения.
Почему SLSA-подписи могут быть валидны при компрометации#
Критическое различие — проверка и целостность выполнения. SLSA не утверждает безопасность процесса, только факт, что артефакт получен через заявленный процесс. Если процесс взломан, подпись остаётся валидной.
SLSA (Supply-chain Levels for Software Artifacts) определяет уровни Build L2/L3, где L3 требует строгой изоляции: отсутствие влияния между сборками, недоступность секретов, отсутствие персистентного состояния.
В Mini Shai-Hulud нарушены ключевые предположения: cache poisoning ломает изоляцию, утечка OIDC токена нарушает секретность, shared state ломает детерминизм.
Что проверить в CI/CD пайплайнах#
| Контроль | Реальность L2 | Требование L3 |
|---|---|---|
| Cache isolation | общий cache | изоляция per-build |
| Secrets | доступны в runtime | недоступны для build steps |
| Build influence | есть cross-run влияние | отсутствует |
| Attestation | фиксирует процесс | требует контролируемого исполнения |
Проверки: проверьте изоляцию cache, ограничьте доступ OIDC, исключите shared state между workflow, аудит runner memory exposure.
Что нельзя переоценивать#
SLSA не ломается как концепция. Ошибка — считать его полной границей безопасности.
Валидная аттестация означает только: артефакт создан указанным pipeline. Она не означает отсутствие компрометации.
https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational, https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan
FAQ#
Почему L3 не остановил атаку#
Потому что реальные CI/CD системы часто не обеспечивают строгую изоляцию: shared cache и доступные токены ломают гарантию.
Делает ли подпись пакет безопасным#
Нет. Только связывает его с процессом сборки.
Основной фикс#
Строгая изоляция сборок: per-build cache, закрытые секреты, отсутствие cross-run влияния.
Связано ли с dependency confusion#
Частично нет. Это уровень ниже: runtime integrity и CI/CD платформа.
Смена перспективы#
Ключевой вопрос смещается: не подписан ли артефакт, а мог ли pipeline быть изменён во время выполнения.
Provenance без изоляции становится записью компрометации.