in-toto

Для чего

in-toto — это формат и framework для проверяемых attestations о цепочке поставки. Он описывает, кто, в каком порядке и с какими входами/выходами выполнял шаги сборки. Заранее заданный layout фиксирует ожидаемую последовательность шагов и допустимых исполнителей; на каждом шаге генерируется подписанная link-метаданная с хешами материалов (вход) и продуктов (выход); финальная verify проверяет, что реальная цепочка совпала с layout. Современная attestation-модель in-toto (statement → predicate, упакованные в DSSE-конверт) — это контейнер, в котором живут и SLSA-provenance, и SBOM-attestations.

in-toto — это «как описано», а не «кто подписал» Подпись (Cosign, Witness) и уровень зрелости (SLSA) опираются на in-toto как на формат. Сам in-toto задаёт структуру доказательства: _type, predicateType, subject (что), predicate (детали). Без согласованного формата провенанс от разных инструментов был бы несопоставим.

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

Запись link-метаданных шага и верификация цепочки против layout (классический CLI in-toto):

# Обернуть шаг сборки: записать материалы/продукты и подписать link приватным ключом
in-toto-run \
  --step-name package \
  --materials src/ \
  --products app-0.1.tar.gz \
  --key functionary.key \
  -- make release

# Проверить, что цепочка соответствует подписанному layout
in-toto-verify \
  --layout root.layout \
  --layout-keys owner.pub

Минимальный скелет современного attestation-statement, который потребляют downstream-инструменты:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v1",
  "subject": [{ "name": "app-0.1.tar.gz", "digest": { "sha256": "<digest>" } }],
  "predicate": {
    "buildDefinition": {},
    "runDetails": {}
  }
}

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

• Описывает не один артефакт, а всю цепочку шагов: подмена или пропуск шага между сборкой и релизом ловится на verify против layout.
• Универсальный контейнер: один формат (statement/predicate/DSSE) переиспользуется для provenance, SBOM, результатов тестов и любых custom-предикатов.
• Криптографически нейтрален к процессу: verify проверяет хеши материалов/продуктов, а не доверие к словам исполнителя.
• Лежит в основе экосистемы (SLSA, Cosign attestations, Witness) — навык переносится между инструментами.

Ограничения

• Layout-модель требует заранее формализовать цепочку шагов и управлять ключами исполнителей (functionaries) — это организационная дисциплина, а не «включил и работает».
• Подтверждает соблюдение описанного процесса, но не корректность самих шагов: вредоносный, но честно описанный и подписанный шаг пройдёт verify.
• Голый CLI не решает хранение и поиск attestations — для этого нужны надстройки (Archivista, GUAC, реестр).
• Богатство формата оборачивается порогом входа: layout, функционарии, sublayouts требуют осмысления, прежде чем дадут отдачу.

Offline / on-premise

Да. Базовая модель полностью локальна: генерация link-метаданных, подпись своими ключами и in-toto-verify против layout не требуют ни одного внешнего сервиса — управление ключами на стороне Организации. Внешняя сеть нужна лишь опционально: когда attestation подписывается keyless через Fulcio/Rekor или складывается в публичную Archivista. В закрытом контуре всё это заменяется внутренним хранилищем и собственным PKI.

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

• М08. Защита цепочки поставки и OSA — attestations как машинный evidence доверия к pipeline.
• П15. SLSA и in-toto provenance — практика: разбор statement/predicate и проверка привязки provenance к источнику.
• П14. Подпись SBOM через Sigstore — где SBOM упаковывается именно в in-toto DSSE-конверт.
• in-toto (нормативная карточка) — роль модели attestations в evidence-базе курса.
• Смежные карточки: SLSA (provenance-предикат поверх in-toto), Cosign (подпись in-toto attestation), Witness (автоматическая генерация in-toto evidence из шагов сборки), GUAC (агрегация attestations в граф).