SBOM и цепочка поставок

Что такое SBOM на самом деле

Software Bill of Materials (опись состава ПО) — это формальная, машиночитаемая опись каждого компонента в программном продукте: прямых зависимостей, транзитивных зависимостей и часто OS-пакетов, запечённых в образ контейнера. Ментальная модель — это этикетка состава на продукте питания: не маркетинговый текст, а буквальный список того, что внутри, в формате, который машина может разобрать, а регулятор — проверить. На практике доминируют два стандарта: SPDX (стандарт ISO, ISO/IEC 5962) и CycloneDX (от OWASP, спроектированный с приоритетом безопасности). Оба выражают одни и те же ключевые факты — имя компонента, версию и уникальный идентификатор под названием purl (package URL, например pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1) — плюс криптографический хеш, чтобы можно было доказать, что артефакт не подменили.

Единственное свойство, ради которого SBOM стоит генерировать, — то, что она захватывает транзитивный граф, а не только верхний уровень. Когда ты делаешь npm install express, ты притягиваешь десятки пакетов, которые никогда не называл; дерево зависимостей реального приложения регулярно доходит до нескольких сотен или тысячи узлов. Уязвимости, которые бьют, почти всегда живут в этом погребённом большинстве — Log4j была на четыре уровня вглубь, — а это ровно там, где человек, читающий package.json, их не видит. SBOM сплющивает весь этот граф в список, который можно запросить: «встречается ли где-нибудь в этой сборке хоть одна версия log4j-core?» превращается из многодневных раскопок в однострочный запрос.

Неочевидное правило: SBOM генерируется на этапе сборки, для каждого артефакта, а не пишется руками. Список зависимостей, поддерживаемый вручную, устаревает в тот момент, когда кто-то поднимает версию в lock-файле, а устаревший — хуже, чем никакой, потому что он уверенно лжёт. SBOM — это выход сборки, привязанный к конкретному digest образа, поэтому он описывает ровно те байты, которые ты задеплоил, а не то, что обещает README.

Почему «затронуты ли мы?» — это весь смысл

SBOM не имеет ценности, лёжа в бакете. Её ценность реализуется, когда выходит новая уязвимость и ты подаёшь SBOM в сканер, который сопоставляет purl каждого компонента с CVE-фидом. Это разница между описью и обнаружением: опись говорит, что у тебя есть; скан говорит, что из этого теперь известно как опасное. Поскольку новые CVE публикуются каждый день против компонентов, которые ты заморозил месяцы назад, сопоставление должно быть непрерывным — уязвимость, которая была чистой на момент сборки, становится критической в день выхода своего CVE, а сохранённая SBOM — это то, что позволяет дотянуться назад и найти её, ничего не пересобирая и не перегрепывая.

Здесь же входит приоритизация, потому что реальный скан против дерева в тысячу узлов возвращает десятки попаданий, а пропатчить их все за неделю нельзя. CVSS — Common Vulnerability Scoring System — даёт каждому CVE базовый балл 0–10, вендоронезависимую серьёзность, сравнимую между командами. Но базовый балл намеренно худший-случай и без контекста: он предполагает, что уязвимый код достижим, а актив открыт. Зрелый ход — наложить средовые и временные метрики CVSS — действительно ли этот компонент на достижимом пути? обращён ли актив в интернет? существует ли эксплойт в дикой природе? — поверх базового балла. CVE с базовым 9.8 в dev-only сборочном инструменте, который ты никогда не поставляешь, — это меньший реальный риск, чем 7.5 в твоём обращённом в интернет сервисе аутентификации. SBOM говорит, где находится компонент, а это ровно тот контекст, что превращает сырой балл в реальный приоритет.

Вторая половина: provenance и доверие

Знать, что ты поставляешь, — лишь половина проблемы цепочки поставок. Вторая половина — доверять, что компонент, который ты притянул, — это тот, который его автор действительно опубликовал, и этот вопрос стал острым после атак вроде SolarWinds (2020), где вредоносный код внедрили в сборочный конвейер, так что подписанный официальный артефакт сам оказался отравлен, и Codecov и захвата npm-пакета event-stream, где легитимный пакет перехватили и выкатили вредоносную версию. Во всех случаях имя зависимости и версия выглядели верно. SBOM сказала бы тебе, что ты запускаешь этот пакет; она не сказала бы, что пакет подменили выше по течению. Этот зазор закрывает provenance.

Provenance — это проверяемые, защищённые от подделки метаданные, отвечающие на вопрос откуда взялся этот артефакт, из какого коммита исходника, собран каким конвейером? — криптографически подписанные, чтобы их нельзя было подделать задним числом. SLSA (Supply-chain Levels for Software Artifacts, читается «сальса») — это фреймворк, который оценивает, насколько этому provenance можно доверять, по уровням: грубо, L1 означает, что provenance существует, L2 — что он подписан сборочным сервисом, а L3 — что сборка прошла в укреплённом, изолированном окружении, которое производитель не может подделать. Цель — комбинированная позиция: SBOM, чтобы знать свои компоненты, provenance, чтобы доверять их подлинности, и SLA на патчинг — вроде сроков, предписанных NIST SP 800-40, — чтобы заведомо плохой компонент чинился по часам, а не когда кто-нибудь заметит.