SLSA

Для чего

SLSA (Supply-chain Levels for Software Artifacts) — это не утилита, а шкала зрелости гарантий о том, как был собран артефакт. Build-трек задаёт уровни L1–L3: от «provenance просто существует» до «provenance выпущен изолированным, защищённым от подделки builder'ом». SLSA отвечает не на вопрос «что внутри артефакта» (это SBOM), а на вопрос «можно ли доверять процессу сборки»: из какого commit, каким builder'ом, по какому workflow он получен.

Provenance против подписи состава Подпись SBOM (см. Cosign) подтверждает что лежит в артефакте. SLSA-provenance подтверждает как и где он собран. Это разные гарантии: артефакт может иметь честный SBOM и при этом быть собран на скомпрометированном runner'е.

Как применяют

SLSA-уровень не «ставится» командой — он достигается настройкой pipeline и проверяется инструментом. На практике provenance генерируется доверенным builder'ом (например, официальным GitHub-генератором), оформляется как in-toto attestation с predicateType: https://slsa.dev/provenance/v1 и верифицируется slsa-verifier с обязательной привязкой к источнику:

slsa-verifier verify-artifact app-linux-amd64 \
  --provenance-path app-linux-amd64.intoto.jsonl \
  --source-uri github.com/<github-owner>/<repository> \
  --source-tag v1.4.0

Ключевой фрагмент проверяемого provenance (декодированный statement):

{
  "predicateType": "https://slsa.dev/provenance/v1",
  "subject": [{ "name": "app-linux-amd64", "digest": { "sha256": "<digest>" } }],
  "predicate": {
    "runDetails": { "builder": { "id": "https://github.com/slsa-framework/slsa-github-generator/..." } }
  }
}

--source-uri обязателен по смыслу: без него verify подтверждает лишь, что provenance подписан, но не что артефакт собран именно из вашего кода.

Сильные стороны

• Даёт общий язык для требований к сборке: «нужен L3» понятнее и проверяемее, чем абстрактное «надёжный pipeline».
• Уровни проверяемы машинно: verify против --source-uri/--builder-id — это и есть подтверждение соответствия уровню, а не декларация.
• Опирается на готовый формат (in-toto provenance) и готовые builder'ы — не требует изобретать собственную модель доверия.
• Закрывает класс атак «подмена сборки» (вредоносный runner, инъекция в build-step), который SBOM и SCA в принципе не видят.

Ограничения

• Это рамка, а не продукт: сам по себе SLSA ничего не генерирует — нужны builder и verifier, и их доверенность придётся обеспечить отдельно.
• Высокие уровни (L3) требуют изолированного, защищённого от подделки builder'а — для on-prem CI это нетривиальная перестройка, а не флаг.
• Provenance подтверждает процесс сборки, но не безопасность исходного кода и не отсутствие уязвимостей в зависимостях.
• Без привязки verify к источнику гарантия вырождается: валидное provenance можно получить и на форк, и на чужую сборку.

Offline / on-premise

Частично. Сама модель уровней инфраструктуры не требует. slsa-verifier может проверять provenance офлайн, если бандл с подписью и нужные материалы доверия выгружены заранее (verify по локальному .intoto.jsonl без обращения к публичному Rekor возможен при оффлайн-бандле). Достижение L2/L3 в закрытом контуре требует собственного доверенного builder'а и, при keyless-подписи provenance, self-hosted Fulcio/Rekor — иначе сетевой доступ к публичным сервисам.

Связанные темы

• М08. Защита цепочки поставки и OSA — provenance как часть контура доверия к сборке.
• П15. SLSA и in-toto provenance — практика: получить и верифицировать build provenance, отрицательный тест.
• SLSA (нормативная карточка) — роль уровней в evidence-базе курса.
• NIST SP 800-218 SSDF — PO.3 (доверенная toolchain) и PS.3.1 (сохранение provenance релизов).
• Смежные карточки: in-toto (формат, в котором живёт provenance), Cosign (подпись provenance и образа), Witness (сбор evidence шагов сборки под те же требования), OpenSSF Scorecard (оценка зрелости проектов-зависимостей).