Атака Shai-Hulud снова напомнила неприятную вещь: SBOM сам по себе не отвечает на главный вопрос во время инцидента — где именно вредоносный или скомпрометированный компонент уже работает. Для компании атака на цепочку поставок начинается не в момент публикации пакета в реестре, а в тот момент, когда этот пакет попадает в её сборку, образ или продакшен-сервис. По данным Dark Reading, защитникам нужна видимость актуального кода и затронутых сервисов, а не только перечень зависимостей.
SBOM, Software Bill of Materials, обычно содержит состав приложения: библиотеки, их версии и иногда сведения о происхождении. Это полезный документ для аудита, управления уязвимостями и ответа на вопрос «используем ли мы компонент X». Но во время атаки на цепочку поставок этого мало. SBOM не обязан сообщать, была ли конкретная версия фактически установлена, попала ли она в финальный контейнер, запущена ли в рабочем окружении и имеет ли доступ к секретам, облачной инфраструктуре или данным клиентов.
Shai-Hulud — показательный случай именно из-за механики распространения. Кампания была нацелена на экосистему npm: вредоносный код попадал в пакеты, а скомпрометированные учётные данные разработчиков и токены могли использоваться для публикации новых заражённых версий. Такая схема превращает зависимость из строки в package-lock.json в возможную точку входа в CI/CD и окружения разработчиков. Формально пакет может присутствовать в каталоге артефактов, но реальный риск будет разным для ноутбука разработчика, тестового контура, внутреннего сервиса и внешнего API.
Отсюда и разрыв между двумя, на первый взгляд, похожими вопросами. «Есть ли у нас эта библиотека?» — вопрос инвентаризации. «Где она исполнялась после появления вредоносной версии и какие полномочия имела?» — вопрос реагирования. Первый часто закрывается сканером зависимостей и SBOM. Для второго нужны данные из систем сборки, реестров контейнеров, Kubernetes, журналов развёртывания, облачных аккаунтов и средств защиты конечных точек. Если эти источники не связаны между собой, команда получит длинный список пакетов, но не приоритеты.
Для российских команд это особенно практичная проблема. Во многих компаниях зависимость проверяют в репозитории, а выпуск продукта живёт отдельной жизнью: образы пересобираются в другом пайплайне, версии пакетов кэшируются во внутреннем registry, а часть сервисов обновляется нерегулярно. В такой схеме ответ «у нас нет уязвимой версии в main» ещё не означает, что её нет в продакшене. Сервис мог быть собран неделю назад, ветка — удалена, а образ — продолжать работать в кластере. Атака на цепочку поставок быстро превращается в археологическую экспедицию по CI-логам.
Практический минимум после сообщения о компрометации пакета выглядит не как один запуск SCA-сканера. Команде нужно сопоставить несколько наборов данных:
- какие версии пакета разрешались и скачивались в CI, на рабочих станциях и из внутренних прокси;
- какие сборки и контейнерные образы получили эти версии;
- какие из образов были развёрнуты и продолжают работать;
- какие секреты, токены и сервисные учётные записи были доступны процессам во время установки и сборки;
- были ли после подозрительного периода необычные публикации пакетов, изменения в пайплайнах или обращения к облачным API.
Это не призыв отказаться от SBOM. Напротив, качественный SBOM остаётся базой: без него труднее быстро отсеять заведомо незатронутые продукты. Проблема возникает, когда его принимают за карту реального исполнения. Документ описывает состав артефакта в определённый момент; инфраструктура меняется постоянно. Пакет мог оказаться транзитивной зависимостью, быть заменён при сборке, не войти в финальный образ или, наоборот, остаться в старом развёртывании после обновления репозитория.
Поэтому владельцам платформ и службам ИБ стоит заранее договориться не только о формате SBOM, но и о связях между артефактом, сборкой и развёртыванием. Полезно хранить идентификаторы сборок, хеши образов и сведения о версиях зависимостей так, чтобы по названию пакета можно было получить список работающих сервисов. Не менее важны короткоживущие токены, минимальные права CI-задач, раздельные учётные записи для публикации пакетов и мониторинг необычных действий с секретами. Эти меры не исключат компрометацию зависимости, но сузят радиус поражения и сократят время расследования.
История Shai-Hulud меняет и метрику зрелости DevSecOps. Вопрос уже не в том, умеет ли организация сформировать SBOM для отчёта. Вопрос — способна ли она за часы доказать, что конкретный вредоносный компонент не исполнялся в её сервисах, либо точно назвать затронутые системы и отозвать их доступы. Чем больше цепочка поставок опирается на открытые пакеты и автоматические пайплайны, тем ценнее становится эта доказуемость.
