SBOM и SLSA: безопасность software supply chain

Сканер нашёл ноль уязвимостей — это ещё не значит, что в registry лежит артефакт из вашего кода. SBOM отвечает, из чего он собран. Provenance — где и как. Подпись и проверка — можно ли этому утверждению доверять. По отдельности это файлы, вместе — контроль выпуска.

Коротко. Выпускайте immutable artifact по digest, генерируйте SBOM в машиночитаемом формате, создавайте provenance на build platform, подписывайте или получайте подписанную аттестацию и проверяйте её перед deploy. SLSA — не сертификат «безопасно», а модель зрелости источника и сборки.

Что именно защищаем

Цепочка поставки начинается с commit и включает зависимости, CI, build image, registry и deployment. Атакующий может подменить зависимость, изменить workflow, украсть upload token, заменить образ после проверки или подсунуть сборку не из того commit. Обычный SAST не доказывает происхождение готового файла.

SBOM: состав, а не гарантия

Software Bill of Materials — перечень компонентов, версий, связей и идентификаторов. SPDX и CycloneDX — распространённые машиночитаемые форматы. SBOM позволяет ответить: есть ли конкретная библиотека в конкретном image и какие релизы надо проверять после новой CVE.

Генерируйте SBOM из финального артефакта или в доверенном build job, а не из ноутбука разработчика. Привязывайте его к digest. Файл без связи с образом быстро становится декоративным приложением к релизу.

AIBOM: модель тоже зависимость

В AI-сервисе одного списка библиотек мало. Зафиксируйте точный идентификатор и ревизию модели, tokenizer, формат весов, квантизацию, лицензию, источник, хеш файлов, runtime, адаптеры и системную конфигурацию. Если используются датасет или набор оценки, у них тоже должна быть версия и происхождение — без выгрузки самих чувствительных данных в публичную аттестацию.

Подписывайте не абстрактное имя модели, а конкретный manifest или digest набора файлов. На deploy проверяйте, что image, модель и конфигурация образуют разрешённую связку. Иначе подписанный контейнер может скачать после запуска другие веса, а ваша provenance будет честно доказывать происхождение только оболочки.

release-manifest.json
├── image: registry/app@sha256:...
├── model: model-store/qwen@sha256:...
├── tokenizer: sha256:...
├── runtime-config: sha256:...
└── eval-set: internal:v17

Для агента добавьте версии prompt policy, разрешённых tools и MCP-серверов. Это не повод называть любой JSON новым стандартом. Задача AIBOM — воспроизводимо ответить, что именно работало в релизе и что надо отозвать после проблемы.

Provenance: история происхождения

Provenance описывает, какой builder, процесс и входы создали artifact. В модели SLSA Build L1 provenance уже существует; на L2 его формирует и подписывает hosted build platform; L3 требует более жёсткой изоляции и защиты build platform. Это накопительные уровни гарантий, а не оценка качества кода.

Ключевая мысль: шаги самого workflow не должны иметь возможность незаметно придумать себе «правильное» происхождение. Чем выше уровень, тем меньше доверия пользовательскому build-коду и больше — изолированному control plane.

Минимальный pipeline

Checkout точного commit, а не плавающей ветки.
Установка зависимостей по lock-файлу.
Тесты и сканирование.
Сборка image без секретов в слоях.
Публикация по digest.
Генерация SBOM и provenance.
Подпись аттестаций доверенным механизмом.
Проверка политики перед допуском в окружение.

Если после подписи вы пересобрали image или перепушили tag, старое доказательство относится к другому digest. Tag удобен людям, digest нужен контролю.

Проверка важнее генерации

Склад SBOM и подписей сам по себе ничего не блокирует. На deploy проверьте digest artifact, доверенного issuer или ключ, репозиторий и workflow, ожидаемый build type, branch/tag и допустимый уровень. При несовпадении политика должна остановить выпуск, а не написать предупреждение в лог, который никто не читает.

commit → hosted build → image@sha256:...
                    ├── SBOM
                    └── signed provenance
deploy policy → verify digest + identity + source → allow / deny

Зависимости и уязвимости

SBOM не заменяет обновления. Настройте регулярное сопоставление компонентов с базой уязвимостей, сроки реакции по severity и исключения с владельцем и датой окончания. Не блокируйте production только по числу CVE без контекста достижимости и эксплуатации, но и не оставляйте вечные «временно принято».

Секреты сборки

Секрет не должен попадать в Docker layer, artifact, SBOM, provenance или лог. Используйте краткоживущую идентичность и секретные mounts, ограничивайте права workflow. Pull request из недоверенного fork не должен автоматически получать production credentials.

Проект для портфолио

Возьмите маленькое приложение и GitHub Actions. Соберите image, опубликуйте по digest, получите SBOM, provenance и проверку перед тестовым deploy. Затем покажите два отказа: попытку развернуть неподписанный image и image из чужого workflow. В README объясните threat model, что именно гарантирует каждый файл и что не гарантирует.

Сам pipeline соберите по гайду GitHub Actions, а доставку декларативного artifact — через GitOps и Argo CD.

Типичные ошибки

SBOM создан, но не привязан к digest;
tag можно перезаписать после сканирования;
подпись есть, но deploy её не проверяет;
workflow закрепляет action по плавающему tag;
provenance генерирует тот же недоверенный скрипт, который он должен контролировать;
уровень SLSA называют аудитом безопасности приложения.

Частые вопросы

SBOM делает продукт безопасным?
Нет. Он делает состав видимым и ускоряет анализ. Уязвимость всё равно надо оценить и устранить.

SLSA заменяет подпись образа?
Нет. SLSA задаёт требования и модель происхождения; конкретная реализация должна создать и проверить доверенное доказательство.

С чего начать маленькой команде?
С immutable digest, SBOM, hosted build provenance и обязательной проверки перед deploy.