«Мы всё сканируем» — почему этого катастрофически мало для безопасности цепочки поставки ПО

Это не гипотетический сценарий. По данным отчёта Verizon за 2025 год, доля взломов с участием третьих сторон удвоилась и достигла 30%. Sonatype за тот же год зафиксировала более 454 600 новых вредоносных пакетов, причём свыше 99% из них — в экосистеме npm. В сентябре 2025-го появился первый самовоспроизводящийся npm-червь: он заразил более 500 пакетов за считанные дни, распространяясь автономно через окружения разработчиков.

Проблема не в том, что у команд нет инструментов. Проблема в том, что инструменты применяются слишком поздно и слишком изолированно. Безопасность цепочки поставки ломается не в одном месте — она ломается на стыках: между зависимостями и сборкой, между сборкой и реестром, между реестром и деплоем.

Где именно ломается доверие

Цепочка поставки ПО — это не только исходный код. Это зависимости, сборочная среда, подписи артефактов, реестры образов и процесс доставки в продакшн. Уязвимость на любом из этих этапов может перечеркнуть всё остальное.

Ниже — сводка ключевых звеньев, типичных рисков и мер защиты, которые реально работают на каждом из них:

Этап	Типичная угроза	Защитная мера	Что даёт
Базовые образы и зависимости	Компрометация upstream, тег указывает на другой digest	Pinning по SHA256, минимальные образы	Устраняет «тихую» подмену
Сборочная среда (CI/CD)	Инъекция кода после code review, компрометация CI-плагинов	Изолированные эфемерные среды, pinning экшенов по commit SHA	Защищает сборку до того, как артефакт создан
Артефакт и его происхождение	Неизвестно, где и как собран образ	SLSA провенанс, подписанные аттестации	Криптографически связывает образ с источником
Реестр образов	Несанкционированные или непроверенные образы	Контроль доступа, верификация подписи	Ограничивает поверхность распространения
Деплой в продакшн	Образ без верифицированного провенанса	Admission controller с policy enforcement	Предотвращает запуск неверифицированных образов
Runtime	Атаки, активирующиеся после деплоя	Поведенческий мониторинг, профили отклонений	Ловит то, что не поймали на входе

Каждый из этих этапов — отдельная точка входа для атакующего. И ни одна из мер не закрывает сразу все бреши.

Фундамент: доверие начинается с образа, а не со сканера

Самый высокий рычаг влияния — выбор базового образа. Каждый контейнер наследует риски своей основы: необновлённые библиотеки, лишние утилиты, оболочки, которые в продакшне не нужны, но атакующему очень удобны.

Сканер уязвимостей видит содержимое образа. Но он не видит, был ли этот образ вообще собран надёжным способом. Здесь в игру вступает разница между двумя инструментами, которые часто путают.

SBOM — это список компонентов: что именно находится внутри артефакта. Аналог списка ингредиентов на этикетке. Он помогает ответить на вопрос «попала ли я под log4shell?» за минуты, а не за несколько дней форензики.

Провенанс — это сведения о том, где, как и из чего артефакт был собран. Если SBOM — список ингредиентов, то провенанс — это сертификат условий производства и неповреждённости упаковки. Без провенанса вы знаете что внутри образа, но не можете быть уверены, что сборочная среда не была скомпрометирована.

Именно поэтому SBOM без провенанса даёт лишь частичную прозрачность. Атаки типа SolarWinds или Codecov не изменили список компонентов — они изменили процесс сборки. SBOM в таких сценариях был бы чист. Провенанс — нет.

Ещё один базовый, но часто игнорируемый приём: pinning по digest, а не по тегу. Тег python:3.12 сегодня и завтра может указывать на совершенно разный образ. Компрометация или случайное изменение upstream тихо попадает в следующую сборку. SHA256-digest фиксирует конкретное содержимое — это не просто «хорошая практика», это устранение целого класса атак одной строкой в Dockerfile.

Сборочная среда как высокоценная цель

Если атакующий компрометирует CI/CD-систему, все ваши code review и сканеры становятся декорацией. Вредоносный код вносится после проверки исходников — туда, куда взгляд ревьюера уже не доходит.

CISA прямо указывает: целостность сборочной системы — это фундаментальный элемент цепочки доверия. Если нельзя доверять системе, которая произвела артефакт, никакое постфактум-сканирование этого не компенсирует.

SLSA (Supply Chain Levels for Software Artifacts) — это не продукт, а модель зрелости, описывающая прогрессивные уровни защиты сборки. На уровне 1 — базовая документация провенанса. На уровне 3 — изолированная, устойчивая к подмене платформа, генерирующая подписанные аттестации, которые невозможно сфабриковать.

На практике это означает: CI/CD должна генерировать подписанные провенанс-аттестации (в формате in-toto) вместе с каждой сборкой образа. Сами аттестации становятся криптографическим доказательством, которое политики деплоя могут верифицировать до того, как образ попадёт в продакшн.

Отдельная точка уязвимости — CI-плагины и GitHub Actions. Большинство команд пиннят версии своего кода, но не пиннят экшены и плагины в CI. Мутабельный тег в CI-конфиге — это та же проблема, что и мутабельный тег образа: завтра он может указывать на что-то другое.

Индустриализация угрозы: это уже не одиночные пакеты

Важно понять масштаб сдвига, который произошёл в 2025 году. Sonatype зафиксировала более 800 пакетов, связанных с группой Lazarus (APT38), сосредоточенных преимущественно в npm. Это уже не отдельные вредоносные загрузки — это производственная линия.

flowchart LR
 A[Публикация пакета-дроппера] --> B[Установка в dev-среде]
 B --> C[Кража токенов и секретов]
 C --> D[Бэкдор и закрепление]
 D --> E[Распространение в CI/CD]
 E --> F[Компрометация downstream]

Примерно 77% пакетов Lazarus включают два и более типа угроз, а около 9% — четыре и более. Это не «плохой пакет» — это первый шаг многостадийного вторжения. Дроппер публикуется маленьким и внешне безобидным, чтобы не привлекать внимание. Потом он скачивает зашифрованную нагрузку с C2-сервера. Потом устанавливает бэкдор.

Самовоспроизводящийся червь Shai-Hulud в сентябре 2025 года пошёл дальше: он распространялся автономно, заражая локально связанные проекты и публикуя заражённые версии легитимных пакетов без ручного шага. Поверхностное сканирование он обходил, скрываясь в дублирующихся файлах и вложенных директориях.

Суть: атаки масштабируются быстрее, чем успевает реагировать ручная проверка. Современное приложение в среднем содержит сотни зависимостей — внимательно изучать каждую из них физически невозможно. Это и есть ставка атакующих.

Контроль доступа: кто вообще решает, что попадает в продакшн

Реестр образов — это дистрибуционный хаб. Если разработчики могут тянуть любой образ из любого публичного реестра без ограничений, цепочка поставки фактически распространяется на всех мейнтейнеров, которых они когда-либо выбирали.

Минимально необходимое: ограничение на использование непроверенных образов, требование верификации подписи перед попаданием образа в продакшн, разграничение прав между сборочными и деплойными аккаунтами.

Здесь работает и принцип наименьших привилегий. Атаки на цепочку поставки часто эксплуатируют избыточно привилегированные сервисные аккаунты или токены с широкими правами. CI-токен не должен уметь пушить в продакшн-реестр. Деплойный токен не должен уметь менять конфигурацию сборки. Ни один кредентиал не должен давать доступ одновременно к исходному коду и продакшн-инфраструктуре.

Policy enforcement через admission controller — это финальный барьер перед запуском образа. Без него все предыдущие инвестиции в провенанс и подписи остаются честным словом: образ без верифицированной аттестации технически ничто не мешает запустить.

Мониторинг: последний рубеж, а не первый

Runtime-мониторинг часто продают как альтернативу контролю на этапе сборки. Это неверная постановка вопроса. Статический анализ и сканирование перехватывают угрозы, которые вы предвидели. Runtime-мониторинг перехватывает те, которые вы не предвидели, — или те, которые активируются только при определённых условиях в продакшне.

Это важный слой. Но если не выстроены предыдущие уровни — доверенный базовый образ, pinning, провенанс, контроль доступа — runtime-мониторинг превращается в попытку поймать компрометацию постфактум. Пожарная сигнализация не заменяет пожаростойкую конструкцию здания.

С чего начинать, если программы нет вообще

Здесь важна честность: разные меры дают эффект на разных этапах зрелости, и не всё нужно делать одновременно.

Немедленный эффект с минимальными усилиями дают pinning по digest и выбор минимальных базовых образов. Это снимает целый класс атак через upstream и не требует переработки процессов. Следующий слой — генерация SBOM при каждой сборке и начало работы с провенансом. Это строит видимость, без которой невозможно ничего более сложного: когда выходит новый CVE, команды с актуальным SBOM определяют затронутые воркло́ды за минуты, без него — начинают многодневное расследование.

Policy enforcement и runtime-мониторинг — это уровень зрелости, который выстраивается поверх первых двух слоёв, а не вместо них.

Главный вывод: безопасность цепочки поставки ломается не потому, что у организаций нет сканеров. Она ломается потому, что доверие к артефактам устанавливается слишком поздно — уже после того, как компрометация могла произойти. Сканер видит содержимое. Провенанс говорит, можно ли доверять тому, как это содержимое появилось. Без pinning, подписанных аттестаций и контроля доступа даже идеальный сканер работает реактивно: вы не предотвращаете подмену, а лишь надеетесь заметить её позже.

Примеры инструментов в материале иллюстрируют подходы, а не являются универсальными рекомендациями. Цифры из отраслевых отчётов отражают тенденции, но не описывают риск для каждой организации одинаково. Материал не заменяет внутреннюю оценку рисков конкретной команды.