Команда получила контейнерный образ, список библиотек и зелёную отметку проверки подписи. Можно ли считать образ доверенным? Для ответа нужно понять, какие утверждения проверены. Список компонентов, неизменность файла и разрешение использовать его в конкретной среде — разные вопросы.
SBOM описывает состав программного продукта и связи компонентов. Форматы вроде CycloneDX и SPDX делают такие сведения машиночитаемыми. Наличие списка само по себе не подтверждает отсутствие уязвимостей или точность способа его получения. CycloneDX, SPDX
Начать с конкретного артефакта
Представим учебный сервис с образом app-demo:release. Имя удобно для человека, но тег может указывать на другую сборку позже. Поэтому результат проверки привязывают к конкретному содержимому — например, digest образа, который фактически будет запускаться.
Далее проверяют связь сопровождающих документов с этим же содержимым. Нельзя приложить SBOM от предыдущей сборки только потому, что имя продукта совпадает. Такой документ может быть корректным сам по себе и одновременно бесполезным для выбранного файла.
Полезно отдельно выписать, что именно попало в инвентаризацию: зависимости приложения, пакеты базового образа, инструменты сборки. Если генератор видит только один manifest, это не автоматически полный состав многослойного контейнера. Требование полноты должно соответствовать реальному объекту проверки.
Происхождение описывает процесс
Provenance отвечает на вопрос, как произведён артефакт. В формате SLSA provenance предусмотрены сведения об определении сборки, её запуске и исполнителе; выходные артефакты связываются с утверждением через subject. Здесь разбирается документированный формат SLSA 1.1, а не заявляется актуальность этой версии для всех внедрений. SLSA 1.1: provenance
Для учебного релиза проверяющий может ожидать конкретный репозиторий, разрешённый workflow и сборочную платформу. Эти ожидания нужно сформулировать до проверки. Если принять любое корректно подписанное утверждение от любого автора, подпись подтвердит лишь то, что неизвестный вам субъект подписал неизвестный вам процесс.
Возможна и более тонкая ошибка: документ выпущен доверенной платформой, но для pull request из недоверенной ветки. Название организации в сертификате не заменяет проверки того, из какого события и источника получилась сборка.
Подпись работает вместе с политикой
Документация Sigstore описывает проверку подписи с ограничением ожидаемой identity и OIDC issuer для соответствующего режима. Условия доверия являются частью проверки, а не декоративным комментарием рядом с командой. Sigstore: verifying signatures
Удобно выразить учебную политику четырьмя вопросами:
- Совпадает ли digest с артефактом, который собираемся запускать?
- Кто выпустил подтверждение и разрешён ли этот субъект?
- Совпадают ли источник и способ сборки с нашим ожиданием?
- Удовлетворяют ли состав и найденные риски требованиям этой среды?
Ответ «да» на первый вопрос не делает остальные ненужными. И наоборот, обнаружение известной уязвимости не объясняет автоматически её достижимость в конкретном приложении: для решения нужны контекст использования и принятая политика риска.
Проверять отрицательные случаи
На синтетическом наборе берут правильный артефакт, другой файл под тем же именем, документ от другой сборки и подпись неразрешённого исполнителя. Ожидаемый результат для каждой комбинации задают заранее. Проверка должна отвергать неподходящие комбинации, а не просто находить рядом любой файл с расширением signature.
Наконец, отделяют проверку происхождения от возможности восстановить выпуск. Даже воспроизводимая сборка не отменяет хранения нужных исходных зависимостей и описания среды. Цель всей цепочки — получить объяснимое основание для запуска конкретного артефакта, а не собрать коллекцию зелёных значков.