Новости и разборы
SBOM и provenance: какие вопросы о сборке они решают
Состав зависимостей и происхождение артефакта помогают проверять выпуск. Разбираем границы этих доказательств и правила допуска в production.
Когда сканер находит уязвимую библиотеку, команда должна понять, в каком выпущенном приложении она присутствует. Когда появляется сомнение в контейнерном образе, нужен ответ на другой вопрос: какой процесс его собрал и из каких исходников? Для этих задач нужны разные доказательства. Один файл с перечнем пакетов не заменяет проверку происхождения выпуска.
Привязать состав к реальному артефакту
SBOM описывает компоненты программного продукта и связи между ними. CycloneDX предоставляет формат для такого описания. Для эксплуатации важна привязка перечня к конкретному выпуску. Инвентаризация рабочего каталога разработчика может не соответствовать контейнеру, который запущен на сервере.
Практическое решение: формировать состав в процессе выпуска и сохранять его рядом с идентификатором образа. Проверять, вошли ли туда системные пакеты и зависимости приложения, если они относятся к выбранной области анализа. Неполноту следует обозначить прямо. Отсутствие библиотеки в отчёте не доказывает её отсутствие в системе, если инструмент не исследовал соответствующий слой.
Для условного сервиса обработки документов это позволяет быстро найти выпуски с определённой версией библиотеки. Но сам перечень ещё не отвечает, получает ли уязвимая функция недоверенные файлы. Этот пример показывает вопрос для расследования, а не результат выполненного проекта.
Проверить происхождение и ожидания
SLSA provenance описывает происхождение артефакта, включая процесс сборки и связанные входные данные. Команде нужно заранее решить, какие значения она считает допустимыми. Подпись от неизвестного сборщика может быть математически корректной и при этом не соответствовать правилам выпуска компании.
В рекомендациях SLSA по проверке рассматриваются подпись, идентификатор артефакта и ожидаемые параметры сборки. Для собственного приложения это можно превратить в правило допуска: принимаем образ с конкретным digest, собранный доверенным процессом из разрешённого репозитория. Исключение должно иметь владельца и причину, иначе проверка быстро становится необязательной.
Нужно проверить и отрицательный сценарий. Образ без доказательства, с другой подписью или с несовпадающим digest должен получать понятный отказ. Если система лишь складывает файлы provenance в архив, но выпускает всё подряд, защитного решения в точке запуска ещё нет.
Где остаются риски
Официальная модель угроз SLSA помогает отделить изменение исходного кода, компрометацию зависимости и подмену результата сборки. Отсюда следует важное ограничение: корректное происхождение не делает вредоносный исходный код безопасным. Если нежелательная правка прошла разрешённый процесс, её всё равно может собрать доверенная инфраструктура.
Поэтому проверку происхождения стоит сочетать с ревью изменений, ограничением полномочий CI и анализом зависимостей. Отдельное внимание требуется установочным скриптам и инструментам сборки: они могут выполнять действия до появления готового артефакта. Область доверия должна включать то, что действительно участвует в выпуске, а не только финальный архив.
Как выбрать первый объём работ
Для небольшой команды разумно начать с одного приложения и одного пути выпуска. Зафиксировать зависимости, связать SBOM с образом, сохранить provenance и поставить проверку перед запуском. Затем проверить ошибочный источник, подмену файла и недоступность сервиса проверки. Нужен заранее согласованный порядок действий, чтобы аварийный выпуск не превращался в бесконтрольный обход.
Оценивать результат лучше по способности ответить на вопросы об установленной версии и объяснить отказ в её запуске. Число созданных отчётов само по себе этого не показывает. Если данные собираются, но никто не отвечает за реакцию на новые сведения, появится архив без операционного эффекта.
При планировании инфраструктуры и выпуска стоит обсудить, какие доказательства команда сможет воспроизводить и проверять. Требования должны соответствовать риску приложения и возможностям его сопровождения.
Источники проверены 7 октября 2026 года. Ссылки SLSA ведут на фиксированную спецификацию 1.0 для воспроизводимости объяснения; материал не представляет её как новейшую версию.
В архиве проекта Debian в Google Cloud доставка изменений перечислена рядом с веб-сервисами, базой данных и управлением процессами. Такой состав показывает, почему учёт выпуска должен охватывать приложение и его окружение. Архив описывает проектный объём: из него нельзя сделать вывод, что SBOM или проверка provenance были внедрены. Для новой системы это отдельная часть требований и приёмки.
Мой исторический материал об удалённом доступе к Debian показывает другую границу: инструкция для одной версии не доказывает совместимость следующих. Поэтому рядом с подтверждением происхождения сборки стоит хранить проверенную среду запуска. Это помогает понять, к какому установленному экземпляру относятся документы выпуска.