SLSA and SBOM in delivery

Зазор доверия, который оставляет прошедшая сборка

Обычный пайплайн отвечает на вопрос «прошёл ли код?». Он не отвечает на «то, что я собираюсь деплоить, — это подлинный, неизменённый вывод того прошедшего прогона, из источника, который контролирую я?». Это разные вопросы, и именно во втором живут атаки на цепочку поставок. SolarWinds (имплант в системе сборки), Codecov (утёкший креденшл bash-uploader’а, переписывавший вывод CI) и бэкдор в XZ Utils 2024 года (вредоносный мейнтейнер протащил обфусцированный код в релизные тарболы, отличавшиеся от git-дерева) — все обошли любой контроль, сканирующий вход. Ни один из них не был injection-багом или непропатченным CVE. Они вмешивались в производство артефакта, а твой сканер зависимостей по своей природе туда не смотрит.

Поэтому проблема цепочки поставок раскладывается на три вопроса, на которые ты обязан уметь ответить про всё, что деплоишь:

• Как это собрано? — provenance сборки: из какого коммита источника, каким сборщиком, с какими параметрами, и без человека, способного молча внедрить шаги. Это область SLSA.
• Это ровно тот артефакт, который собрали? — целостность, устанавливаемая криптографической подписью над дайджестом артефакта и проверяемая в момент допуска.
• Что внутри? — его bill of materials: каждый компонент и версия, чтобы при следующем Log4Shell ответить «затронуты ли мы?» по индексу, а не лихорадочным grep по всем сервисам. Это и есть SBOM.

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

SLSA: provenance и лестница уровней

SLSA (Supply-chain Levels for Software Artifacts, читается «сальса») — это фреймворк, который оценивает, насколько процессу сборки можно доверять. Его ключевой артефакт — provenance: подписанное, машиночитаемое утверждение, что этот дайджест вывода произведён из той ревизии источника, тем сборщиком, с этими параметрами. Смысл — неотрекаемость самой сборки: проверяющий ниже по потоку может убедиться, что бинарь перед ним действительно вышел из пайплайна, на который ссылается, а не подменён после.

SLSA v1.0 определяет Build-трек с уровнями, которые наращивают гарантии о сборщике, а не объём бумаг:

Решающий скачок — L2 → L3. На L2 подписанный provenance доказывает, что артефакт не подменили после сборки, но скомпрометированный сборочный скрипт всё ещё может солгать в provenance, который сам генерирует. L3 требует, чтобы сборка шла в изолированном эфемерном окружении, где provenance генерирует платформа, а не контролируемые пользователем шаги, — так что вредоносный шаг, подменивший объект SolarWinds, не сможет заодно подделать чистую аттестацию о самом себе. Эта изоляция и есть настоящая граница безопасности; номер уровня — лишь сокращение для «насколько может солгать плохой шаг сборки».

Практический путь неэффектен: большинство управляемых CI (GitHub Actions с официальным генератором SLSA, GCB, Tekton Chains) дают подписанный provenance L2/L3 ценой изменения воркфлоу. Ловушка — self-hosted раннер, который ты переиспользуешь между джобами: общее состояние между сборками возвращает тебя ниже L3, какую бы аттестацию ты ни выдавал, потому что предыдущая джоба может отравить следующую.

Подпись: keyless и журнал прозрачности

Provenance хорош ровно настолько, насколько хороша подпись над ним, а управление ключами — место, где умирают программы подписания. Современный ответ — keyless-подпись (cosign из Sigstore): вместо долгоживущего приватного ключа, лежащего в хранилище секретов в ожидании утечки, сборщик аутентифицируется короткоживущей OIDC-личностью (например, workload identity у GitHub Actions), Fulcio выдаёт эфемерный сертификат, привязанный к этой личности, делается подпись, ключ выбрасывается, а всё событие записывается в Rekor — публичный журнал прозрачности, дополняемый только в конец.

Это даёт два свойства, недостижимых для статического ключа. Во-первых, красть нечего — ключ подписи жил секунды. Во-вторых, запись в Rekor доказуемо неподменна: у задним числом сделанной или подделанной подписи нет соответствующей записи в журнале, поэтому проверка может требовать «должна быть в Rekor до момента T». Ты проверяешь по личности и provenance, а не по вере в то, что ключ хранили в безопасности три года.

SBOM: ответ «затронуты ли мы?» за минуты

SBOM (Software Bill of Materials) — это список ингредиентов: каждый компонент, версия и лицензия внутри артефакта в стандартном машинном формате — SPDX или CycloneDX. Ты генерируешь его на сборке (например, Syft или родным экспортёром твоего сборочного инструмента), прикладываешь как подписанную аттестацию рядом с provenance и кладёшь туда, где его сможет запросить реагирование на инциденты.

Его ценность асимметрична и проявляется ровно в один тип дня. Когда в декабре 2021 рвануло Log4Shell, команды без SBOM сутками гоняли find по сотням сервисов, чтобы выяснить, вшит ли log4j-core — часто транзитивно, на три уровня вглубь, внутри fat JAR, о содержимом которого они не подозревали. Команды с запрашиваемым индексом SBOM за минуты ответили «в каких из наших 400 задеплоенных артефактов есть log4j-core в затронутом диапазоне?» и сузили реакцию до тех немногих, где он был. SBOM не предотвращает уязвимость; он схлопывает твоё среднее-время-до-ответа с суток до запроса, а это разница между управляемым раскатом и выходными в панике.

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