От дайджеста артефакта к актуальному доказательству

Каждый релиз проходит единую цепочку доказательств. На каждом этапе хранятся доказательства, привязанные к дайджесту артефакта, и каждый этап имеет ровно одно состояние: MISSING, RECORDED или SIGNED. После развёртывания Watch продолжает проверять актуальность доказательства.

Источник Сборка Сканирование Вердикт Решение Развертывание Watch
Начать бесплатно Читать документацию

После первоначальной настройки у вас будет:

  • 1. Фильтрация накопившихся уязвимостей до результатов сканирования достижимого риска для реального артефакта
  • 2. Экспортируйте подписанный Decision CapsuleПодписанный экспортируемый пакет доказательств, запечатывающий все входные и выходные данные решения о релизе для офлайн-аудита и детерминированного воспроизведения для каждого решения о продвижении выпуска.
  • 3. Один полный переход от разработки к промежуточной стадии с доказательствами

Где место пакета „Стела“

CI создает и тестирует артефакты. Stella оценивает право на продвижение выпуска, развертывается на целевых объектах, не относящихся к Kubernetes (Compose, SSH/WinRM) и сохраняет криптографически проверяемые записи решений без замены существующих инструментов CI.

Гейт из любой системы CI/CD

Что бы ни выполняло ваши развёртывания — Jenkins, шаги Octopus, GitLab CI, GitHub Actions, шелл-скрипт на сборочной машине — контроль через Stella устроен одинаково: добавьте этап, запускающий CLI.

Команда завершается с ненулевым кодом, когда контроль блокирует, поэтому этап падает и конвейер останавливается. Больше ничего настраивать не нужно: ни входящего вебхука, ни callback-URL, ни сетевого пути из Stella в вашу сборочную систему.

Подпись происходит при сборке, поэтому свидетельство не зависит от того, какой CI ее создал.

The gate call →

Четыре входные категории питают цепочку доказательств. Доказательства подписываются там, где они созданы, а затем проверяются на уровне управления.

Реестры · Доказательство конвейера через CLI · Консультации и источники VEX · Секреты — Every source named, and what each one feeds →

Цепочка доказательств

Семь стадий, один дайджест артефакта. Это страница, которую вы открываете, когда кто-то спрашивает, что запущено и почему это разрешено.

Посмотреть в работе · 4 мин

Один релиз, отклонённый на гейте, и один одобренный, последовавшее развёртывание, запечатанная Decision Capsule за каждым решением, рабочий набор exposure, сужающийся до того, что действительно блокирует, цепочка custody и матрица эстейта.
Экран Chain of Custody: семь этапов от Source до Watch, каждый помечен MISSING
Chain of Custody в консоли Stella Ops, локальный стек разработки. Каждый этап этого субъекта показывает Missing — нет происхождения исходников, нет доказательства сборки. Ничего не додумывается, чтобы закрыть эти пробелы, и ничто пустое не считается исправным.

Каждый этап находится ровно в одном из трех состояний:

MISSING

Для этого этапа доказательств нет. Он показывает MISSING, пока доказательства не появятся.

RECORDED

Доказательства существуют и привязаны к дайджесту артефакта, но еще не подписаны.

SIGNED

Доказательства содержат подпись DSSEDead Simple Signing Envelope – простой гибкий стандарт для подписи произвольных данных криптографическими подписями и могут быть проверены в автономном режиме.

  1. 1

    Источник

    Коммит и репозиторий, из которого, по утверждениям, получен артефакт, записаны из вашего конвейера — никогда не выводятся.

  2. 2

    Сборка

    Доказательство конвейера через CLI ↑

  3. 3

    Сканирование

    SBOMSoftware Bill of Materials – полный перечень всех пакетов и зависимостей вашего ПО и анализ уязвимостей, привязанный к этому точному дайджесту. Новый дайджест означает новое сканирование; результаты никогда не переносятся в сборку, из которой они не были созданы.

  4. 4

    Вердикт

    Оценка политикой: достижимый риск, а не простые количества ↓

  5. 5

    Решение

    Результат действия политики и любое одобрение человека, записанное с указанием точной версии политики, которая его создала.

  6. 6

    Развертывание

    Развертывание утвержденного дайджеста в указанной среде: что запускалось, где и когда.

  7. 7

    Watch

    Непрерывное сравнение текущих дайджестов с утвержденными дайджестами. Дрейф обнаруживается, а не устраняется.

Оценка политикой: достижимый риск, а не простые количества

Гейты сравнивают подписанные результаты с версионированной политикой. Анализ достижимости сужает блокировку до результатов на пути, который может выполнить ваш код. Он охватывает Go, Java, C#/.NET, JavaScript и TypeScript, Python, Rust, PHP и Ruby; результаты для других языков остаются в рабочем наборе и по умолчанию не помечаются как недостижимые.

На демонстрационном экране «Экспозиция»: 7 результатов → 1 блокирующий (достижимый × не исправленный). Он останавливает релиз. Остальные шесть остаются видимыми через фильтр.

Контекст: ~85% критических уязвимостей контейнеров находятся в неактивном коде (отчет Sysdig 2024 Container Security Report).

Терминал
$ stella gate evaluate --env staging --image sha256:8c1a4f…

Команды, как показано в консоли продукта (v1.0-RC1).

О проверке, которую не удалось выполнить, сообщается как NOT EVALUATED и записывается в вердикте. Это никогда не считается пропуском.

Экран продвижений в консоли Stella Ops: шесть состояний жизненного цикла — от «ожидает утверждения» до «выведено из эксплуатации» — со статусом и сигналом риска по каждому продвижению
Продвижения в консоли Stella Ops, показаны на демонстрационных данных. Каждое продвижение находится ровно в одном состоянии жизненного цикла, и состояние его гейта следует за ним.
Поставку прежде всего блокирует достижимая, не исправленная и значимая для политики уязвимость. Остальные результаты доступны через один фильтр.

При каждой неудачной проверке указывается сработавшее правило, прочитанные им доказательства и результат сканирования, стоящий за ним. Ответ находится в вердикте, а не в повторном запуске сканеров или переписке с командой безопасности. «Почему мой выпуск заблокирован?» →

Если Stella Ops недоступна, гейт блокирует.

Тайм-аут сканера или policy engine по замыслу считается отказом, а не пропуском, и во всём CLI нет флага fail-open. Артефакт, результат сканирования которого не удалось получить, не развёртывается.

Выпуск во время сбоя — осознанный и подотчётный акт, а не обходной путь: подписанное, ограниченное и срочное исключение, записанное на оператора, который его принял, и настроенное до первого использования.

Как работает break-glass, подробно →

Якоря доказательств

Каждое утверждение ссылается на проверяемые артефакты доказательств, процесс воспроизведения и спецификацию.

Ссылки на доказательства и методологию: Доказательства и аудит | Спецификация Decision Capsule | Эксплуатация и развёртывание

Развертывание: утвержденные дайджесты для целей, не относящихся к Kubernetes.

На этапе развертывания выводится утвержденный дайджест и фиксируется, что и куда было отправлено. Целевые объекты — это инфраструктуры, которые большинство инструментов выпуска игнорирует.

  • → Проекты Docker Compose
  • → Хосты SSH/WinRM — без агентов по архитектуре
  • → Поэтапная, канареечная и сине-зелёная стратегии
  • → Откат повторно указывает на заведомо исправный дайджест, доказательства которого уже имеются в файле.
  • → Каждое развертывание записывает дайджест, среду и время.

Откат — это проверенное развёртывание уже одобренного дайджеста, а не исключение из процесса.

Эксплуатация и развёртывание · Развертывание на серверах без установки агентов

Watch: доказательство должно продолжаться.

Утверждение — это момент времени. После развертывания Watch сравнивает каждый запущенный дайджест с утверждённым дайджестом для этой службы и среды. Развертывание остаётся безагентным — на ваши хосты ничего не устанавливается. Наблюдение выполняет агентская служба Stella Ops, которая читает дайджесты образов, реально работающих на доступных ей демонах Docker. Агентская служба работает внутри вашей собственной установки Stella, а не на ваших хостах, и читает через Docker API.

Отклонение в определении продукта:

“текущий дайджест не является утвержденным/развернутым дайджестом (неутвержденный или измененный образ)”

Среды, которые Stella невозможно наблюдать, показаны как недоказанные и никогда не считающиеся здоровыми.

Единица, которую наблюдает Watch, — это контейнер, определяемый по дайджесту образа, поэтому обнаружение дрейфа покрывает контейнеризированные нагрузки на ваших хостах, будь то Docker по SSH, Compose или демон Windows.

Граница, названная прямо: то, что работает вне контейнера, находится вне доказательства Watch. Файлы, службы или исполняемые файлы, развёрнутые на голом хосте, несут доказательство развёртывания — кто, что, когда и из какого релиза, идентифицированного дайджестом, — но не перепроверяются непрерывно по дайджесту образа.

См. дрейф во всей инфраструктуре →

Подробнее

К чему подключается Stella Обзор архитектуры Что получают аудиторы

Готовы увидеть в действии?

Начать бесплатно Читать документацию

Смотреть все функции | Доказательства и аудит | Документация