Witness

Для чего

Witness оборачивает шаг сборки и автоматически собирает evidence о том, как он выполнялся. Команда witness run запускает любой процесс (например, make), а пока он идёт — фиксирует материалы и продукты, git-состояние, окружение, запущенные команды, и упаковывает всё это в подписанный in-toto attestation через набор подключаемых attestor'ов. Затем witness verify проверяет собранные attestations против политики: были ли пройдены нужные шаги, теми ли исполнителями, с ожидаемым набором evidence. По сути это «runtime-сборщик provenance», избавляющий от ручного написания link-метаданных.

Чем Witness отличается от голого in-toto in-toto задаёт формат и требует, чтобы вы сами сгенерировали link-метаданные. Witness автоматизирует их сбор: подключаемые attestor'ы (git, environment, command-run, products) наполняют attestation за вас, а policy-движок задаёт правила приёмки. Это уровень оркестрации поверх in-toto.

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

Запись attestation вокруг шага сборки и его проверка по политике:

# Обернуть сборку: собрать evidence и подписать attestation
witness run \
  --step build \
  --key signer.key \
  --outfile build.attestation.json \
  -- make release

# Проверить артефакт против политики (какие шаги/исполнители обязательны)
witness verify \
  --policy policy.signed.json \
  --publickey policy-ca.pub \
  --artifactfile app-0.1.tar.gz \
  --attestations build.attestation.json

Опционально attestations выгружаются и ищутся через сервис Archivista (--enable-archivista, --archivista-server <url>), а подпись может идти keyless через Sigstore.

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

• Снимает ручную работу: evidence (git, окружение, команды, продукты) собирается attestor'ами автоматически во время реального запуска шага.
• Policy-движок переводит требования в проверяемое правило приёмки — «шаг build обязан быть подписан этим ключом и содержать git-attestor».
• Совместим с экосистемой in-toto/SLSA: на выходе стандартный attestation, который потребляют те же verifier'ы и графы.
• Гибкость за счёт подключаемых attestor'ов — можно добавлять источники evidence под конкретный pipeline.

Ограничения

• Полнота доказательства определяется набором подключённых attestor'ов: чего не собрали, того в attestation нет — легко получить «зелёную», но неинформативную проверку.
• Политику и ключи исполнителей нужно проектировать и сопровождать — мощность policy-движка оборачивается сложностью сопровождения.
• Evidence фиксирует, что происходило во время запуска, но не выносит суждения о намерении: компрометация внутри обёрнутой команды попадёт в attestation как «штатный» продукт и пройдёт policy-проверку.
• Менее распространён и более «нишев», чем Cosign; зрелость интеграций (особенно вокруг Archivista) стоит проверять под свою задачу.

Offline / on-premise

Частично. Ядро (witness run и witness verify с ключевой подписью и локальной политикой) работает полностью офлайн — никаких внешних сервисов. Сетевые зависимости — опциональны: keyless-подпись через Fulcio/Rekor, доверенные метки времени (TSA) и хранение/поиск attestations в публичной Archivista. В закрытом контуре всё это заменяется собственным PKI и self-hosted Archivista либо обычным файловым хранилищем.

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

• М08. Защита цепочки поставки и OSA — сбор evidence о сборке как часть контура доверия.
• П15. SLSA и in-toto provenance — практика по provenance, к которой Witness даёт автоматический способ генерации attestations.
• П16. GitLab CI security gate — где witness verify встраивается обязательным шагом gate.
• Смежные карточки: in-toto (формат и модель, которые Witness автоматизирует), SLSA (уровни provenance, под которые собирается evidence), Cosign (альтернативный путь подписи attestations), GUAC (граф, в который складываются собранные attestations).