Безопасность цепочки поставок

Защита всей цепочки - от исходного кода до развёрнутого артефакта. Каждое звено (CI/CD-пайплайны, менеджеры зависимостей, реестры пакетов, кэши сборки, процессы релизов) представляет собой поверхность атаки. Компрометация любого из них позволяет внедрить вредоносный код в финальный продукт, вообще не трогая репозиторий с исходниками.

Поверхности атаки

CI/CD-пайплайны. GitHub Actions, GitLab CI и аналогичные системы выполняют код с доступом к секретам и учётным данным для публикации. Опасные типы триггеров (см. pwn-request-pattern) открывают привилегированный контекст внешнему коду. Мутабельные теги action'ов позволяют злоумышленникам незаметно подменять их код. Кэши сборки можно отравить, внедрив полезную нагрузку в будущие сборки (github-actions-cache-poisoning). Как только код начинает выполняться на CI-runner'е, сгенерированные прямо в процессе OIDC-токены можно извлечь из памяти и использовать для прямой публикации (ci-runner-token-extraction).

Зависимости. Скомпрометированный upstream-пакет отравляет всех, кто от него зависит. Особенно опасно окно сразу после свежего релиза: в статье Astral как мера защиты описан cooldown зависимостей - задержка обновлений, помогающая не подхватить временно скомпрометированную версию.

Реестры пакетов. Долгоживущие API-токены для PyPI, NPM, crates.io - частый вектор захвата. Взлом учётной записи или кража токена позволяют публиковать вредоносные версии под доверенным именем пакета.

Артефакты релизов. Теги можно перезаписать через force-push, релизы - изменить уже после публикации, а бинарники - раздавать по мутабельным URL. В атаке на цепочку поставок Trivy как раз использовался force-push тега для подмены легитимного релиза.

Паттерны защиты

Отказываться от учётных данных везде, где возможно. Trusted Publishing (федерация идентификации на базе OIDC) позволяет CI публиковать пакеты в реестры без сохранённых токенов. Реестр вместо этого доверяет подтверждению подлинности от CI-провайдера. Это частный случай более широкого паттерна ephemeral-credentials; в long-lived-keys подробно объясняется, почему токенов реестров в принципе не должно существовать.

Фиксировать всё. Привязывать action'ы к SHA коммитов, жёстко фиксировать версии зависимостей, сопоставлять URL скачивания с криптографическими хэшами. Мутабельность - враг: везде, где указатель можно незаметно перенаправить, злоумышленник может подсунуть вредоносное содержимое.

Минимальные привилегии. Начинать с нулевых прав и выдавать каждому job'у только то, что ему действительно нужно. Изолировать секреты по средам развёртывания (deployment environments), а не открывать их на уровне всего репозитория.

Аттестация и верификация. Sigstore создаёт криптографическую связь между артефактами и сгенерировавшими их workflow. Пользователи могут проверить, что скачанный файл действительно собран ожидаемым CI-пайплайном.

Неизменяемые релизы. Артефакты и теги после публикации нельзя модифицировать. Это блокирует атаку с подменой релиза задним числом.

Одобрение несколькими людьми. Процесс релиза требует подтверждения более чем от одного человека, что снижает риск компрометации отдельного аккаунта.

Задержка обновлений (cooldown зависимостей). Намеренно откладывать обновление зависимостей после выхода новых версий. Большинство случаев отравления цепочки через зависимости вскрываются быстро, поэтому пауза в несколько дней отсеивает худшие инциденты.

Социальные связи. Знать мейнтейнеров upstream-проектов. Помогать им улучшать безопасность пайплайнов. Участвовать в рабочих группах по безопасности экосистем. Защита цепочки поставок - это отчасти задача координации.

Инструменты

• zizmor - статический анализ для workflow в GitHub Actions, находит незафиксированные action'ы и коммиты-самозванцы
• pinact - автоматическая фиксация action'ов по SHA коммитов
• Sigstore - беспарольная (keyless) подпись и верификация артефактов
• Trusted Publishing - публикация без постоянных секретов на базе OIDC (PyPI, crates.io, NPM)
• Dependabot / Renovate - автоматическое обновление зависимостей с поддержкой cooldown

Атаки на доверие к мейнтейнерам

Не всякий риск в цепочке поставок сводится к утечке учётных данных или компрометации пайплайна. Сложнее всего защищаться от перехвата доверия к мейнтейнерам (maintainer-trust capture) - когда контрибьютор годами накапливает легитимный доступ, а затем злоупотребляет им, как в инциденте с xz-utils. Родственный сбой, maintainer-governance-ambiguity, приводит к тому, что сегодня даже легитимная передача проекта выглядит как атака, вынуждая пользователей тратить ресурсы на долгую проверку, если изменения прав не прозрачны и не поддаются аудиту. Связанный фактор: unmaintained-scanner-pressure выступает вынуждающей силой, которая подталкивает стабильные проекты именно к ситуациям вида "приходит новый мейнтейнер", что после xz воспринимается со стороны как атака.

Заметные инциденты

• 2026-05 fsnotify - спор мейнтейнеров, принятый за захват проекта. Библиотека на Go с 321 тысячей зависимых проектов; взаимный отзыв прав между arp242 и mattn со стороны выглядел как атака на цепочку поставок. Код скомпрометирован не был. Наглядный пример maintainer-governance-ambiguity и издержек внешнего наблюдателя в эпоху после xz. См. fsnotify-maintainer-dispute.

• 2026-05-11 TanStack - scope @tanstack/* в npm. 84 вредоносные версии 42 пакетов были опубликованы за 6 минут через цепочку из трёх звеньев в CI: workflow pull_request_target, собиравший код из форка (pwn-request-pattern), отравление кэша Actions через границу доверия fork -> base -> production (github-actions-cache-poisoning) и извлечение OIDC-токена из памяти runner'а (ci-runner-token-extraction). Токены npm украдены не были; легитимный шаг Publish Packages даже не запускался. Внешнее обнаружение произошло примерно через 20 минут благодаря Socket.dev и открытому issue. См. tanstack-npm-supply-chain-postmortem с разбором всей цепочки и выводов по каждому рубежу защиты.

• 2026 Shai-Hulud / Checkmarx - Bitwarden CLI. Пакет @bitwarden/cli версии 2026.4.0 от Bitwarden был опубликован в npm с вредоносной нагрузкой bw1.js через скомпрометированный GitHub Action в их CI/CD-пайплайне. Нагрузка скачивала среду Bun, расшифровывала червя Shai-Hulud и собирала токены GitHub/npm, SSH-ключи, историю шелла, учётные данные AWS/GCP/Azure, секреты GitHub Actions и конфигурации MCP, выгружая их наружу через автоматическое создание публичного репозитория в собственном GitHub-аккаунте каждой жертвы. Пакет провисел около 19 часов; пострадали 334 разработчика. Ситуацию усугубили два фактора: критичный для безопасности CLI распространялся через npm, а не как единый статический бинарник, а CI/CD-пайплайн не заметил внедрённый файл перед публикацией. Общий контекст вокруг Bitwarden описан в marius-bitwarden-not-recommended.

См. также

• open-source-security-astral - подробный разбор реализации этих паттернов в компании Astral
• long-lived-keys - аргументация Людвига о том, что проблема токенов реестров характерна вообще для всех долгоживущих ключей
• ephemeral-credentials - базовый паттерн, на котором строится Trusted Publishing
• hazmat - изоляция среды исполнения для AI-агентов написания кода (другой уровень проблемы доверия)
• macos-executable-replacement - куда дальше распространяется ущерб на macOS: выполнения кода от имени текущего пользователя (а именно это получает вредоносная зависимость или установочный скрипт) достаточно, чтобы незаметно подменить бинарник внутри любого скачанного из веба приложения
• living-off-the-land - аналог на уровне среды исполнения: атакующие используют легитимные предустановленные бинарники вместо доставки вредоносного ПО
• gtfobins - эталонный Unix-каталог бинарников, пригодных для атак LotL: справочник для red team и чек-лист для сисадмина
• hardening-container-images - пересборка контейнерного образа на стороне потребителя с генерацией SBOM, OpenVEX, provenance по SLSA и keyless-подписью через cosign
• dockerscan - сканер для Docker-образов, покрывающий сразу несколько этих областей (CIS benchmark, supply-chain, секреты, CVE, рантайм)