SBOM + SLSA в DevSecOps: практическая стратегия снижения рисков supply‑chain атак

Резюме для руководителей

Цепочка поставок ПО сегодня ломается не там, где вы «плохо написали код», а там, где вы не можете доказать, что именно собрали, из чего, кем и на каких условиях — и что при сборке никто не подменил входы или артефакты. SBOM и SLSA закрывают эту «дыру доказуемости» с двух сторон: SBOM описывает состав, а SLSA — достоверность процесса сборки и происхождение артефакта (provenance). 

Практический эффект, если внедрять правильно: - вы быстрее находите уязвимые компоненты «по ингредиентам» (SBOM) и меньше тонете в ложных срабатываниях, если добавляете VEX/оценку применимости (CycloneDX VEX / OpenVEX);  - вы снижаете вероятность «тихой» подмены в CI/CD за счёт подписей, аттестаций, проверяемого provenance и политик допуска (SLSA Build L2–L3 + in‑toto/DSSE + Sigstore/cosign);  - вы превращаете DevSecOps из набора разрозненных сканеров в замкнутый цикл контроля: генерируем → подписываем → публикуем → проверяем → допускаем → мониторим. 

Важно: SBOM не является «волшебным патчем» и сам по себе не предотвращает атаки — официальные рекомендации прямо подчеркивают, что SBOM — это базовый слой прозрачности, на который «наслаиваются» процессы и инструменты управления рисками. 

Почему цепочка поставок стала зоной риска

Supply‑chain атаки почти всегда эксплуатируют один из трёх разрывов контроля.

Первый разрыв — непрозрачные зависимости: ваша сборка тянет десятки/сотни транзитивных пакетов, и вы не видите их как управляемый актив. Это особенно болезненно при инцидентах уровня Log4Shell‑типа (уязвимость массовая, а реальная проблема — «где она у нас вообще есть?»). Именно эту проблему SBOM формулируется как «формальная запись деталей и отношений компонентов» — по смыслу «этикетка состава», но для ПО. 

Второй разрыв — недоказуемая сборка: даже если код в репозитории чистый, остаётся вопрос: «а артефакт в проде точно собран из этого кода, именно этим процессом, и никто не вмешался?» На это отвечает SLSA: в Build Track уровни повышают гарантии целостности и проверяемости provenance — от «provenance существует» до «сборки защищены и изолированы». 

Третий разрыв — доверие к публикации и доставке: подписи, реестры, обновления, скрипты в CI — идеальная точка для подмены. Поэтому современные практики делают упор на подпись артефактов и метаданных, прозрачные журналы и контроль допуска, например через Sigstore/cosign и средства валидации на стороне кластера. 

Дальше начинается самое интересное (и самое практичное): SBOM и SLSA — не конкуренты, а «две половины одного доказательства».

SBOM на практике

Определение SBOM и зачем он нужен «по‑взрослому»

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

NTIA в «Minimum Elements for SBOM» выделяет минимальный базис, который делает SBOM действительно применимым: данные (поля), автоматизация (машиночитаемость и генерация) и процессы (практики распространения и использования). 

В зрелой DevSecOps‑модели SBOM используют не только «для отчёта», а как: - инвентаризацию того, что реально поставляется и запускается; - основу для vulnerability management (поиск CVE/OSV по компонентам); - поддержку лицензионного и регуляторного комплаенса (особенно у SPDX, исторически сильного в лицензиях); - источник фактов для инцидент‑менеджмента (быстро выяснить blast radius и сделать приоритизацию). 

CycloneDX и SPDX: ключевые различия

Оба формата решают задачу SBOM, но с разной философией и сильными сторонами.

CycloneDX развивается OWASP Foundation и Ecma TC54; позиционируется как стандарт BOM для снижения киберрисков. В репозитории спецификации прямо указано, что CycloneDX — стандарт Ecma (ECMA‑424), а спецификация охватывает не только SBOM, но и VEX, VDR и даже Attestations (CDXA). 

SPDX — международный открытый стандарт (ISO/IEC 5962:2021). На странице спецификаций указано, что текущая версия — SPDX 3.0, а более ранняя ветка 2.3 остаётся широко используемой; в релиз‑заметках для 3.0 подчёркнуты «breaking changes» относительно 2.3. 

Таблица сравнения CycloneDX и SPDX

Про VEX: почему одного SBOM мало

SBOM отвечает на вопрос «что внутри», но не всегда на вопрос «уязвимость реально эксплуатируема у нас?». Для этого и существует VEX (Vulnerability Exploitability eXchange): представление информации о применимости/эксплуатируемости уязвимости в конкретном продукте.

CycloneDX описывает поддержку VEX как способ представлять exploitability‑данные. OpenVEX — минималистичная реализация VEX в виде JSON‑LD, развивается как спецификация сообщества под эгидой OpenSSF; в репозитории отмечено, что спецификация пока в статусе draft. 

Практическая рекомендация: если вы быстро утонули в сотнях CVE на образ — VEX/эквивалентная практика «обоснованных исключений» (с аудит‑следом) экономит недели жизни, но только если она стандартизована и подписана как артефакт, а не записана в Wiki «на честном слове». 

SLSA и аттестации

Что такое SLSA и чем «уровни» отличаются от SBOM

SLSA (Supply‑chain Levels for Software Artifacts) — рамочная спецификация, которая вводит общий язык «уровней гарантий» для цепочки поставок: что именно защищено, где возможна подмена и какие требования нужны, чтобы повысить доверие к артефакту. Репозиторий проекта описывает SLSA как фреймворк «от source до service» и общий язык для уровней целостности supply chain. 

Если SBOM — это инвентарная ведомость, то SLSA — это доказательная база для вопроса «как это было произведено». В центре SLSA — provenance (происхождение/контекст сборки), оформленное как набор машиночитаемых аттестаций, предназначенных для автоматического принятия решений политиками (policy engines). 

SLSA v1.2: треки и уровни

В SLSA v1.2 спецификация разделена на треки: Build Track и Source Track. Страница Tracks описывает эту идею напрямую: разные аспекты угроз, разные уровни и паттерны использования. 

Build Track (уровни Build L0–L3) даёт гарантии вокруг сборки и provenance: - Build L0 — «нет гарантий» (отсутствие SLSA). - Build L1 — provenance существует (помогает против ошибок, но легко обходится/подделывается). - Build L2 — сборка на hosted платформе, которая генерирует и подписывает provenance; появляется защита от подмены после сборки. - Build L3 — hardened builds: усиленная платформа, изоляция запусков и защита секретов подписи от пользовательских шагов сборки; повышенная стойкость к подмене во время сборки. 

Source Track (Source L1–L4) — про управление исходниками и доказуемость процессов изменения кода: от «версионируется» до «обязательный двухсторонний review». В требованиях Source Track прямо перечислены уровни и их смысл, включая то, что на L4 требуется code review двумя доверенными участниками. 

Таблица: уровни SLSA v1.2 «человеческим языком»

На чём «держится» SLSA технически: in‑toto, DSSE и predicateType

SLSA опирается на модель аттестаций, где метаданные предназначены для автоматической проверки политиками. Формат аттестаций часто связывают с in‑toto Attestation Framework: это спецификация для «проверяемых утверждений» о том, как произведён софт. 

DSSE (Dead Simple Signing Envelope) — простой стандарт подписи произвольных данных; он помогает избегать классов атак «подменили тип/контент» и упрощает упаковку подписанных заявлений. 

SLSA определяет provenance‑predicate (тип предиката) через predicateType: "https://slsa.dev/provenance/v1" и отдельно предупреждает использовать именно это значение. 

Как это встраивается в DevSecOps

NIST SSDF прямо рекомендует набор практик безопасной разработки, которые «встраиваются в каждый SDLC» — это близко к сути DevSecOps: безопасность не как «аудит после релиза», а как системные проверки, артефакты и доказательства, живущие вместе с CI/CD. 

Роль SBOM и SLSA в этой картине — сделать DevSecOps измеримым и проверяемым: - SBOM становится «данными о том, что мы поставили» (что сканировать, за чем следить, что запрещать политикой). - SLSA становится «данными о том, как мы это произвели» (можно ли доверять артефакту и метаданным, можно ли автоматически допустить в прод).

В идеале это сводится к простому управленческому правилу: не выпускать артефакт без SBOM и без проверяемого provenance, а в окружениях повыше (prod/regulated) — не разворачивать то, что не прошло верификацию подписи/аттестаций. 

Интеграция в CI/CD: шаги, инструменты, автоматизация

Ниже — практичная «лесенка» внедрения, которую можно растянуть на недели/кварталы, не ломая процессы.

Базовый сценарий: SBOM + скан + публикация артефактов

1) Генерация SBOM на каждый build/releaseSyft умеет генерировать SBOM и выдавать несколько форматов, включая SPDX и CycloneDX. Trivy тоже умеет генерировать SBOM в CycloneDX (и в целом позиционирует это как часть supply‑chain практик). 

2) Сканирование уязвимостей по SBOM/lockfilesGrype сканирует контейнеры, файловые системы и SBOM на известные уязвимости; это удобно, потому что SBOM становится универсальным входом сканирования. OSV‑Scanner предназначен для поиска уязвимостей в зависимостях и интегрируется в CI; он поддерживает работу с lockfiles/manifest‑ами и SBOM‑подобными входами. 

3) Публикация SBOM рядом с артефактомСовременный практичный паттерн — хранить SBOM и аттестации в том же OCI‑реестре, что и образы/артефакты, связывая их как referrers/subject. Спецификации OCI 1.1 описывают возможность ассоциировать подписи/аттестации и метаданные с образами единым способом. 

Следующий уровень: подпись и provenance (SLSA‑стиль)

4) Подпись артефакта и метаданных (SBOM, attestations)Sigstore описывает модель проверки, где сверяется «кортеж» подписи, сертификата/ключа и артефакта с записью в Rekor (журнал прозрачности). Cosign поддерживает keyless‑подпись через OIDC: получает сертификат у Fulcio и публикует запись в Rekor, а подпись — рядом с образом в OCI‑реестре. 

5) Генерация provenance‑аттестацииDocker Buildx/BuildKit поддерживает provenance attestations по схеме SLSA (есть переключение версий схемы provenance). Сама спецификация SLSA формализует provenance predicateType и требования к нему. 

6) Верификация при деплое (policy gate)Kyverno показывает практика‑ориентированный путь: политики могут блокировать запуск неподписанных образов и проверять Sigstore‑bundle/attestations, включая SLSA provenance. 

Псевдокод пайплайна: SBOM → attestation → verification

pipeline "build_release" {  stage "checkout" {    git clone --depth=1    git verify-commit-signatures(optional_but_recommended)  }  stage "build" {    # hermetic-ish build where possible    build_artifact()    run_tests()  }  stage "sbom" {    sbom = generate_sbom(format="cyclonedx-json")     # e.g., syft/trivy    store(sbom, "artifact.sbom.cdx.json")  }  stage "scan" {    findings = scan_vulns(input=sbom)                 # e.g., grype/osv-scanner    enforce_policy(findings, fail_on="critical+exploitable")    # optionally emit VEX/OpenVEX for false positives / non-exploitable cases    vex = create_vex(findings, decisions, justifications)    store(vex, "artifact.vex.json")  }  stage "provenance_attestation" {    prov = generate_provenance_slsa(predicateType="https://slsa.dev/provenance/v1")    attest(prov, subject=artifact_digest)             # DSSE/in-toto style envelope  }  stage "sign_and_publish" {    sign(artifact_digest)                             # e.g., cosign sign    sign(sbom)                                        # attach SBOM as OCI referrer    sign(prov)                                        # attestations are signed too    publish_all_to_registry()  }  stage "deploy_gate" {    verify_signature(artifact_digest, identity="ci@org", issuer="oidc")    verify_attestation(artifact_digest, type="slsa-provenance", min_level="Build L2")    verify_policy(sbom, denylist, allowed_licenses, required_metadata)    deploy()  }}

Ключевая мысль: безопасность появляется не в «генерации файла SBOM», а в том, что генерация, подпись, публикация и верификация превращаются в непрерывную автоматическую цепочку. 

Контроли обнаружения и предотвращения: что реально работает

Ниже — набор мер, которые «склеивают» SBOM и SLSA в устойчивую систему. Важно, что эти контроли не абстрактны: почти у каждого есть конкретный автоматизируемый артефакт/проверка.

Подпись артефактов и метаданных

Подпись без проверки — полумера. Sigstore подчёркивает, что «полный потенциал» достигается именно при верификации подписанных артефактов. Для практики это означает: подпись должна проверяться в CD (а в идеале — на admission‑уровне Kubernetes). 

Provenance и аттестации как «проверяемые факты»

SLSA Build L2 требует, чтобы provenance генерировалась и подписывалась самой hosted build‑платформой; а Build L3 усиливает платформу: изоляция запусков и защита секретов подписи от пользовательских шагов сборки. Это напрямую снижает класс атак «встроился в CI и подменил результат».

Сканирование уязвимостей «по составу», а не «по файловой системе»

Grype прямо позиционирует сканирование SBOM как вход. Это удобно для скорости и повторяемости. OSV‑Scanner — другой подход: смотреть на зависимости через lockfiles/manifest‑ы и автоматизировать это в CI. Практика: один сканер редко покрывает всё идеально, но SBOM даёт вам единый «контракт данных», который можно скармливать нескольким движкам.

Dependency pinning и контроль источников

Атаки класса dependency confusion показывают, что «разрешение зависимостей» — это часть периметра безопасности, а не просто удобство разработки. Публикации о dependency confusion описывают механику, где пакет с тем же именем в публичном репозитории перехватывается менеджером зависимостей при неверных настройках. Минимальный набор мер: строгие настройки источников пакетов, приоритет private‑registry, запреты на «плавающие» версии в прод‑сборках и обязательные lockfiles в CI.

Воспроизводимые сборки и «after‑the‑fact reproducible build»

SLSA Build L2 допускает, что provenance может быть сгенерирована и подписана через «послефактум воспроизводимую сборку» (или эквивалентный механизм), если это обеспечивает доверие к provenance. Это важный сигнал: reproducible builds — не религиозная практика, а инженерный инструмент, позволяющий проверять, что артефакт действительно соответствует исходникам и описанному процессу.

Контроль изменений в исходниках (Source Track)

В Source Track требования включают сохранение истории, выпуск source provenance и усиление техконтролей вплоть до обязательного двухстороннего review на уровне L4. Если у вас нет защищённых веток и нормального review‑процесса, «идеальный SLSA в сборке» не спасёт от сценария «в репозиторий тихо влили вредоносный коммит».

Управление, соответствие и реагирование на инциденты

Технические меры без управления превращаются в «галочки». Хорошая новость: SBOM и SLSA как раз помогают сделать управление предметным, потому что дают артефакты, которые можно проверять.

Политики, роли, аудит

Рекомендации NIST SSDF построены как практики, интегрируемые в SDLC, и хорошо ложатся в модель разделения ответственности между командами разработки, платформенной командой и безопасностью. 

Полезный RACI‑скелет (очень приземлённый): - Platform/DevOps: стандартизирует пайплайны, build‑платформы, хранение SBOM/attestations, ключи/идентичности для подписи. - Security/AppSec: определяет политики (что блокируем), источники уязвимостей, процесс исключений/VEX, требования к уровням SLSA. - Разработка: исправляет зависимости, внедряет pinning, обеспечивает воспроизводимость/детерминизм, поддерживает метаданные продукта.

Для организаций, которые хотят системного подхода к «SBOM‑экосистеме», существуют профильные рекомендации по управлению SBOM как элементом SCRM/кибербезопасности (например, guidance по SBOM management в государственных/критических контекстах). 

Инцидент‑response: как SBOM и provenance реально ускоряют разбор

В инциденте самое дорогое — время на ответы: - «Какие продукты затронуты?» - «Какие версии?» - «Где это развернуто?» - «Можно ли доверять нашим артефактам, или сборка скомпрометирована?»

SBOM ускоряет анализ области поражения (blast radius), а provenances/attestations помогают отличить «компонент уязвим» от «артефакт подменён в процессе сборки/публикации». Это ровно та логика «прозрачности шагов и исполнителей», которую закладывает in‑toto. 

Практический совет: храните SBOM и аттестации не «где‑то в артефактах CI», а централизованно и неизменно (OCI‑реестр, объектное хранилище с immutability, журнал прозрачности). OCI 1.1 спецификационно поддерживает ассоциацию метаданных с образами, что делает такой паттерн естественным.

Кейс‑уроки: что ломалось в реальности и какие выводы

SolarWinds (Orion/SUNBURST): атака показала, что компрометация сборочной цепочки и доставка «легитимных» обновлений может масштабироваться на тысячи организаций. Публичные разборы и алерты подчёркивают масштаб и необходимость пост‑компромиссной охоты/ремедиации. Урок: без защищённой build‑платформы и проверяемых provenance вы не отличите «мы выпустили» от «за нас выпустили». 

Codecov Bash Uploader: злоумышленник модифицировал скрипт загрузчика, из‑за чего могла утекать CI‑информация/секреты. CISA описывала это как compromise supply chain через несанкционированные изменения Bash Uploader. Урок: скрипты в CI — это тоже зависимости; их нужно фиксировать по хэшу/версии, подписывать, минимизировать секреты и проверять provenance того, что запускается. 

XZ Utils backdoor (CVE‑2024‑3094): вредоносный код попал в upstream‑tarballs (в т.ч. версии 5.6.0+), что отражено в NVD и первичных обсуждениях oss‑security. Урок: доверие «к исходникам в Git» не равно доверию «к релизным тарболлам/пакетам»; нужны воспроизводимость, проверяемое происхождение и контроль того, что именно используется в сборке. 

3CX: троянизированное легитимное ПО, распространяемое пользователям; анализы подчёркивают, что вредоносная активность исходила из подписанного бинарника. Урок: подпись «вендора» без вашей политики проверки происхождения и доверенных сценариев обновления может быть недостаточной; нужно ограничение каналов поставки и проверка attestations на стороне потребителя. 

event-stream (npm): инцидент показал риск передачи владения пакетом и внедрения вредоносной зависимости; npm публично описывал удаление вредоносных версий из registry. Урок: управление зависимостями — это управление риском поставщиков; SBOM + политики по источникам/версиям + мониторинг аномалий важнее «раз в год обновим зависимости». 

Проверочный список и дорожные карты по размеру команды

Ниже — максимально прикладная часть: что делать, в каком порядке, сколько усилий и какие инструменты подходят.

Таблица: рекомендации по инструментам «по кейсам»

Дорожная карта для маленькой команды

Портрет: 1–2 DevOps, несколько сервисов, релизы часто, времени мало.

Приоритет «максимум эффекта за минимум усилий» (обычно 1–2 недели инженера): 1) Генерировать SBOM на каждый релиз (Syft или Trivy). 2) Сканировать по SBOM и блокировать критичные уязвимости (Grype/OSV‑Scanner). 3) Публиковать SBOM рядом с артефактом (в артефакты CI или в OCI‑реестр как referrer). 

Дальше (ещё 1–2 недели, если не упираться в «идеал»): 4) Подписывать release‑артефакты (cosign keyless) и добавить базовую проверку в CD. 5) Начать генерировать provenance (Build L1→L2 по смыслу) через BuildKit/buildx или CI‑генераторы, если доступны. 

Дорожная карта для средней команды

Портрет: платформа общая, микросервисы, есть security‑функция, требования от заказчиков.

Приоритет (4–8 недель суммарно, параллельно): - Стандартизировать build‑пайплайны и перейти к hosted build‑платформе, которая может уверенно выдавать signed provenance (цель: Build L2 как минимум). - Ввести политики допуска: «в прод только подписанное» + «должна быть provenance и SBOM». Kyverno может закрыть admission‑сторону для Kubernetes‑окружений. - Запустить процесс VEX/исключений с аудит‑следом, иначе SCA будет тормозить выпуск. - По исходникам поднять уровень Source Track: защищённые ветки, обязательные статусы/чеки, усиление review (движение к Source L3–L4). 

Дорожная карта для enterprise

Портрет: десятки команд, регуляторика/аудит, сложные цепочки поставщиков.

Приоритет (квартал+): - Централизованный «supply‑chain control plane»: единые политики, единый реестр артефактов, единое хранение SBOM/attestations, единый аудит. OCI‑подход (subject/referrers) снижает фрагментацию хранения. - Целевое состояние по SLSA: Build L3 для ключевых продуктов (изоляция, секреты подписи недоступны шагам), Source L4 для критичных репозиториев. - Метрики и compliance‑доказательства: почему конкретный релиз допустили, какие attestations проверены, какие исключения VEX действуют и кто их утвердил. SLSA как раз проектировалась, чтобы feed‑ить policy engines, а не «лежать PDF‑кой». - Увязка с SSDF‑практиками (NIST) как «скелетом» безопасной разработки для закупок/аудита. 

Если вы хотите, я могу адаптировать диаграммы и псевдокод под конкретный стек (GitHub Actions / GitLab CI / Jenkins / Tekton, Kubernetes или VM‑деплой), а также подготовить «политики допуска» в виде примеров (Kyverno/OPA) — так, чтобы это можно было почти без изменений вставить в инфраструктурный репозиторий.