Supply chain атаки и защита: SLSA, Sigstore, SBOM

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

За последние пять лет supply chain атаки превратились из теоретической угрозы в массовую практику. Случаи вроде компрометации SolarWinds, Log4Shell, регулярных инцидентов с npm-пакетами показали: безопасность продакшена больше не сводится к защите своего кода — она охватывает всю цепочку поставки софта. Разбираем устройство современных supply chain атак, фреймворки защиты SLSA и Sigstore, концепцию SBOM и практическое внедрение в команде разработки.

Что такое software supply chain

Software supply chain — полная цепочка артефактов, кода и процессов, через которые проходит софт от написания до запуска в продакшене. Она включает: исходный код приложения и зависимостей; инструменты сборки (компиляторы, упаковщики); CI/CD-пайплайны; registry-системы (npm, PyPI, Maven Central, Docker Hub); инфраструктуру развёртывания.

На каждом из этих этапов есть возможность для атаки. Компрометированный maintainer npm-пакета может опубликовать вредоносную версию. Скомпрометированный CI/CD-сервер может встроить вредоносный код в сборку. Перехваченное соединение с registry — подсунуть подменённый артефакт. Сам исходный код может содержать backdoor от инсайдера или взломанного контрибутора.

Известные supply chain инциденты

За последние несколько лет произошло несколько крупных инцидентов, изменивших отношение индустрии к supply chain security.

SolarWinds (2020) — атакующие внедрили вредоносный код в Orion — продукт мониторинга, используемый тысячами организаций включая правительственные. Заражённое обновление распространилось через стандартный канал доставки. Десятки компаний и государственных агентств были скомпрометированы.

event-stream (2018) — популярная npm-библиотека с миллионами загрузок в неделю. Сопровождающий передал управление неизвестному волонтёру, который через несколько месяцев внедрил вредоносный код для кражи криптовалюты. Инцидент показал хрупкость доверия в open-source экосистеме.

Log4Shell (2021) — критическая уязвимость в библиотеке логирования Log4j2, используемой повсеместно в Java-экосистеме. Не атака на сам процесс поставки, но демонстрация масштаба зависимости индустрии от одной библиотеки.

colors.js / faker.js (2022) — автор популярных npm-пакетов в знак протеста выпустил версии с бесконечным циклом, ломающие приложения. Несколько тысяч пакетов, зависящих от них, начали падать в продакшене.

XZ Utils (2024) — обнаружен backdoor в популярной библиотеке сжатия данных, внедрённый через долгосрочную социальную инженерию: атакующий несколько лет был активным контрибутором, постепенно набирая доверие, и в итоге получил коммит-доступ. Backdoor мог обеспечить удалённое выполнение кода через SSH на серверах, использующих скомпрометированную версию.

Типичные техники атак

Несколько распространённых техник в современных supply chain атаках.

Typosquatting — публикация пакетов с именами, похожими на популярные библиотеки, в надежде на опечатки разработчиков. expres вместо express, requets вместо requests. Когда разработчик случайно ставит вариант с опечаткой, вредоносный код попадает в его окружение.

Dependency confusion — атака на компании, использующие внутренние пакеты с private registry. Атакующий публикует в публичный registry пакет с тем же именем и более высокой версией. При неправильной настройке CI/CD приоритет получает публичная (вредоносная) версия.

Компрометация maintainer-а. Получение доступа к учётной записи сопровождающего популярного пакета через фишинг, утечку паролей, social engineering. Дальше — публикация версии с backdoor под видом обычного обновления.

Trojanized dependencies. Создание полезного на первый взгляд пакета с вредоносным функционалом внутри. Пакет может корректно выполнять заявленную функциональность, но дополнительно красть данные, открывать обратные соединения, майнить криптовалюту.

Build pipeline compromise. Атака на CI/CD-системы для встраивания вредоносного кода в сборку без изменения исходников. Особенно опасна, потому что код в репозитории остаётся чистым, а атака происходит на этапе компиляции.

SBOM: Software Bill of Materials

Первый шаг защиты — знать, что именно входит в твой софт. SBOM (Software Bill of Materials) — формальный документ, перечисляющий все компоненты программы: библиотеки, версии, лицензии, происхождение, контрольные суммы. Аналог «состава» на упаковке продукта в супермаркете.

Без SBOM команда часто не знает точно, что использует. Транзитивные зависимости (зависимости зависимостей) могут добавлять сотни пакетов, о которых разработчик никогда не слышал. Когда выходит уязвимость в какой-то библиотеке, без SBOM невозможно быстро понять, затронут ли её продукт.

Два основных формата SBOM: SPDX (стандарт Linux Foundation) и CycloneDX (от OWASP). Оба покрывают одинаковые задачи с разными подходами к структуре. Современные инструменты сборки могут генерировать SBOM автоматически: Syft, sbom-tool от Microsoft, специализированные плагины для Maven, Gradle, npm, Cargo.

SLSA: фреймворк безопасности supply chain

SLSA (Supply-chain Levels for Software Artifacts) — фреймворк от Google, описывающий требования к безопасности процесса сборки софта. Состоит из уровней зрелости, постепенно усиливающих защиту от различных атак.

SLSA Level 1 — базовый: процесс сборки документирован, артефакты имеют метаданные о том, как были созданы. Это минимальный уровень доверия — известно, что собрано, как и кем.

SLSA Level 2 — добавляется требование контролируемой среды сборки: сборка идёт в защищённом CI/CD, не на локальной машине разработчика. Метаданные сборки криптографически подписаны.

SLSA Level 3 — требуется изоляция сборок друг от друга, защита от компрометации одной сборки через другую. Источник кода (репозиторий) и среда сборки управляются как security-критические системы.

SLSA Level 4 — высший уровень: два-человеческое ревью изменений в коде и в инфраструктуре сборки, формальная верификация процесса. Подходит для критически важного софта (финансовый сектор, государственные системы).

SLSA — не сертификация, а roadmap зрелости. Команды постепенно повышают уровень: сначала добиться SLSA 1 (документация), потом 2 (контролируемая сборка), потом 3 (изоляция). SLSA 4 — для немногих критически важных проектов.

Sigstore: подписи и прозрачность

Sigstore — open-source проект для cryptographically signing и verification артефактов разработки. Основная идея: каждый артефакт (Docker-образ, npm-пакет, бинарник) подписан, и любой может проверить подпись через публичный transparency log.

Sigstore состоит из нескольких компонентов: Cosign (инструмент подписания и проверки), Fulcio (certificate authority), Rekor (transparency log). Особенность подхода — keyless signing: разработчик подписывает артефакт через свою OIDC-идентичность (Google, GitHub, Microsoft), без необходимости управлять долгоживущими ключами.

Keyless signing решает проблему ключевого менеджмента — главную сложность классических PKI-систем. Не нужно безопасно хранить приватный ключ годами; не нужно обращаться с ним при каждой сборке; не нужно отзывать ключи при увольнении инженера. Подпись привязана к моменту и идентичности, а не к ключу.

Transparency log Rekor — публичная append-only база подписей. Любой может проверить, что артефакт был подписан в определённое время определённой identity. Это создаёт audit trail: если оказывается, что вредоносный артефакт был подписан, можно точно определить, чья identity использовалась.

Provenance: откуда пришёл артефакт

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

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

При развёртывании provenance проверяется: подпись действительна, происхождение совпадает с ожидаемым (правильный репозиторий, правильная ветка, правильный CI/CD), все зависимости из доверенных источников. Только при успешной проверке артефакт допускается в продакшен.

Vulnerability scanning и SCA

SCA (Software Composition Analysis) — анализ компонентов программы на наличие известных уязвимостей. Инструменты SCA берут SBOM проекта, сверяют с базами уязвимостей (NVD, OSV, GitHub Advisory Database), и сигнализируют о найденных проблемах.

Популярные SCA-инструменты: Dependabot (встроен в GitHub), Snyk, JFrog Xray, Trivy, Grype. Большинство интегрируются с CI/CD, проверяя каждый PR на новые уязвимости и блокируя слияние при критических находках.

Важно различать наличие уязвимой версии и реальную эксплуатируемость. Уязвимая функция в библиотеке может не использоваться в данном проекте, тогда уязвимость теоретическая. EPSS (Exploit Prediction Scoring System) и Reachability Analysis помогают приоритизировать уязвимости — какие из них реально нужно срочно фиксить, какие можно отложить.

Container image signing

Docker-образы — критическая часть современной supply chain. Подмена образа в registry или подделка образа в момент развёртывания может скомпрометировать всю систему. Подписание образов — стандартная практика для production-окружений.

Cosign sign image <registry>/<repo>:<tag> — типичная команда подписания. Verify-команда на стороне Kubernetes-кластера или admission controller проверяет подпись перед запуском контейнера. Образы без валидной подписи не допускаются.

В Kubernetes интеграция выполняется через admission controllers вроде Connaisseur, Cosigned, Kyverno. Они перехватывают запросы на создание подов и проверяют подписи образов через Sigstore. Если подпись недействительна или отсутствует, под не создаётся.

Защита CI/CD pipelines

CI/CD — критическая точка supply chain. Компрометация runner-а позволяет атакующему модифицировать любой код, проходящий через пайплайн. Несколько практик защиты CI/CD.

• Эфемерные runners: каждая сборка идёт в чистой среде, после завершения уничтожается. Атакующий не может оставить backdoor для использования в следующей сборке.
• Минимальные права: каждый job имеет только те доступы, которые реально нужны. Деплой-job не должен иметь доступа к исходникам других проектов.
• Защищённые секреты: production-секреты не доступны на этапе сборки, только при развёртывании. Используются специализированные решения вроде HashiCorp Vault.
• Pinned actions / dependencies: CI/CD-зависимости (GitHub Actions, плагины Jenkins) фиксируются по точным версиям с хешами, не по тегам, которые могут быть перезаписаны.
• Reproducible builds: возможность пересобрать тот же артефакт независимо и убедиться в идентичности.

Внутренние registry и proxy

Корпоративная практика — использование внутренних registry для зависимостей. Все npm, Maven, PyPI, Docker-зависимости качаются через корпоративный proxy: JFrog Artifactory, Nexus, GitHub Packages, Sonatype Nexus.

Преимущества подхода: контроль над тем, какие версии используются (можно блокировать уязвимые); кэширование (защита от исчезновения внешних пакетов); скорость (внутренняя сеть быстрее, чем внешние registry); audit (известно, кто и когда использовал какие зависимости).

Внутренний registry дополнительно может проводить автоматическое сканирование загружаемых пакетов: проверка хэшей, scan уязвимостей, проверка лицензий. Зависимость с найденной проблемой блокируется до ручного review.

Часто задаваемые вопросы

Откуда начинать улучшение supply chain security?

С генерации и хранения SBOM для каждого продакшен-артефакта. Без понимания, что именно используется, остальные меры малоэффективны. После SBOM — внедрение SCA-инструмента в CI/CD для автоматической проверки уязвимостей. Далее — подписание артефактов и проверка подписи при развёртывании.

Стоит ли всем переходить на keyless signing через Sigstore?

Для большинства команд — да. Keyless signing значительно проще классических PKI-систем и достаточно для целей supply chain security. Исключения — компании со строгими compliance-требованиями, где может требоваться сертифицированное PKI с долгосрочными ключами (например, finance, government).

Что делать с уязвимостью в зависимости, для которой нет патча?

Несколько стратегий. Использовать форк с исправлением (если кто-то уже исправил). Сделать собственный патч и форкнуть библиотеку. Заменить уязвимую библиотеку на альтернативу. Изолировать уязвимую функциональность (если она используется ограниченно) через дополнительные защитные меры. Самое плохое — игнорировать, надеясь, что не атакуют.

Достаточно ли использовать только Dependabot?

Dependabot хорошо ловит уязвимости в зависимостях, но это лишь часть supply chain security. Не покрывает: подмену артефактов, компрометацию CI/CD, dependency confusion, проблемы в исходном коде. Полная защита требует комплексного подхода: SBOM, SCA, signing, secure CI/CD, audit-процессы.

Что такое pinning и зачем оно нужно?

Pinning — фиксация зависимостей на конкретных версиях или хешах вместо использования диапазонов вроде ^1.2.0. Защищает от автоматического обновления на скомпрометированную версию. Минус — нужно сознательно обновлять зависимости, нет автоматического получения security patches. Подход — pinning + автоматизированный процесс контролируемого обновления через PR с ревью.

Как обеспечить SLSA-compliance в существующем проекте?

Поэтапно. Начать с SLSA 1: документировать процесс сборки, сохранять метаданные. Перейти на SLSA 2: вынести сборки в защищённый CI/CD, добавить подписание. SLSA 3 требует серьёзных инвестиций в инфраструктуру: изоляция, security-критическое управление репозиториями и CI/CD. SLSA 4 — обычно проекты с особо высокими требованиями.

Заключение

Supply chain security перестал быть нишевой темой для специалистов по информационной безопасности. За последние пять лет это стало мейнстрим-практикой для любой команды разработки, серьёзно относящейся к безопасности своих продуктов. Регуляторы (включая исполнительные приказы в США и директивы в ЕС) делают supply chain security обязательным элементом, а не опциональным улучшением.

Технологический стек защиты сформировался за последние годы. SBOM как фундамент знания о составе софта. SLSA как roadmap зрелости процессов. Sigstore как инструмент подписания и верификации. SCA-инструменты для непрерывного отслеживания уязвимостей. Защищённые CI/CD-процессы как основа доверия к artifact pipeline. Каждый из этих компонентов решает свою задачу; вместе они образуют интегрированную систему защиты.

Команды, серьёзно инвестирующие в supply chain security, получают не только лучшую защиту от атак, но и операционные преимущества: ясное понимание зависимостей, возможность быстро отреагировать на новые уязвимости, доверие со стороны клиентов и партнёров. В мире, где громкие инциденты типа SolarWinds и XZ становятся регулярными, supply chain security превращается из «приятного дополнения» в обязательную часть профессионального инженерного процесса.