Від артефактного аналізу до живого доказу
Кожен реліз рухається єдиною магістраллю. Кожен етап містить докази, прив’язані до дайджесту артефакту, і перебуває рівно в одному стані: MISSING, RECORDED або SIGNED. Після розгортання Watch постійно перевіряє, чи доказ залишається чинним.
Після початкового налаштування ви матимете:
- 1. Ваш перший образ, відсканований за допомогою SBOM + аналізу досяжності
- 2. Підписана
Decision CapsuleПідписаний експортований пакет доказів, що запечатує всі вхідні та вихідні дані рішення про реліз для офлайн-аудиту та детермінованого відтворення, що підтверджує результати сканування - 3. Один повний перехід від розробника до постановки з доказами
Де місце Stella Ops
Stella Ops знаходиться між вашим CI та серверами. CI збирає образи. Stella Ops вирішує, чи можна їх просунути, розгортає на не-Kubernetes-цілі (Compose, SSH/WinRM) та експортує докази для аудиту.
Гейт з будь-якої системи CI/CD
Що б не виконувало ваші розгортання — Jenkins, кроки Octopus, GitLab CI, GitHub Actions, шелл-скрипт на складальній машині — контроль через Stella влаштовано однаково: додайте етап, який запускає CLI.
Команда завершується з ненульовим кодом, коли контроль блокує, тож етап падає і конвеєр зупиняється. Більше нічого налаштовувати не потрібно: ані вхідного вебхука, ані callback-URL, ані мережевого шляху зі Stella до вашої складальної системи.
Підпис з'являється під час збірки, тому докази не залежать від того, який CI його створив.
Чотири категорії вхідних даних живлять хребет. Докази підписуються там, де їх подають, а потім перевіряються керуючою площиною.
Реєстри · Докази з конвеєра через CLI · Рекомендації та VEX джерела · Таємниці — Every source named, and what each one feeds →
Магістраль збереження доказів
Сім стадій, один артефактний дайджест. Це сторінка, яку ви відкриваєте, коли хтось запитує, що працює і чому це було дозволено. Подивитися в дії · 4 хв
Кожен етап знаходиться рівно в одному з трьох станів:
MISSING
Доказів для цього етапу немає. Він показує MISSING, доки докази не зʼявляться.
RECORDED
Докази існують і пов'язані з артефактним дайджетом, але ще не підписані.
SIGNED
Докази мають DSSEDead Simple Signing Envelope – простий гнучкий стандарт для підпису довільних даних криптографічними підписами підпис і можуть бути перевірені офлайн.
- 1
Джерело
Коміт і репозиторій, звідки артефакт нібито походить, записані з вашого конвеєра — ніколи не були зроблені висновками.
- 2
Будівництво
- 3
Сканування
SBOMSoftware Bill of Materials – повний перелік усіх пакетів та залежностей вашого ПЗта аналіз вразливостей, пов'язаний саме з цим дайджестом. Новий дайджест означає нове сканування; Результати ніколи не переносяться у збірку, з якої вони не були створені. - 4
- 5
Рішення
Результат воріт і будь-яке людське схвалення, зафіксовані з точною версією політики, яка це призвела.
- 6
Розгортання
Впровадження затвердженого дайджесту у іменованому середовищі: що працювало, де і коли.
- 7
Дивіться
Безперервне порівняння запускових дайджестів із затвердженими дайджестами. Дрейф виявляється, а не припускається.
Оцінювання шлюзу: досяжний ризик, а не необроблена кількість
Шлюзи оцінюють підписані результати за версійованою політикою. Аналіз досяжності звужує блокування до результатів на шляху, який може виконати ваш код. Він охоплює 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).
Перевірка, яка не була проведена, повідомляється як НЕ ОЦІНЕНА і фіксується у вердикті. Це ніколи не вважається пропуском.
Що блокує доставку — досяжна, нефіксована, релевантна для політики експозиція першими. Довгий хвіст знаходиться в одному фільтрі.
Кожна провалена перевірка містить назву правила, яке було спущено, докази, які вона прочитала, і знахідки, що стоїть за цим. Відповідь у вердикті — не в повторному запуску сканерів чи повідомлень із командою безпеки. «Чому мій реліз заблоковано?» →
Якщо Stella Ops недоступна, гейт блокує.
Тайм-аут сканера або policy engine за задумом вважається відмовою, а не пропуском, і в усьому CLI немає прапорця fail-open. Артефакт, результат сканування якого не вдалося отримати, не розгортається.
Випуск під час збою — свідомий і підзвітний акт, а не обхідний шлях: підписане, обмежене та строкове виключення, записане на оператора, який його ухвалив, і налаштоване до першого використання.
Proof anchors
Кожна претензія посилається на перевіряні артефакти доказів, робочий процес відтворення та документацію специфікації.
Посилання на докази та методологію: Evidence and Audit | Decision Capsule spec | Operations and Deployment
Розгортання: затверджені дайджести на цілі безKubernetes
Етап Deploy розгортає затверджений дайджест і фіксує, що куди пішло. Цілі — це інфраструктури, які більшість релізних інструментів ігнорують.
- → Docker Compose проєкти
- → SSH/WinRM хости — за задумом без агентів
- → Стратегії ролінгу, канарки та синьо-зелених
- → Відкат знову посилається на відомий добрий дайджест, докази якого вже є в базі
- → Кожне розгортання фіксує дайджест, середовище та час
Відкат — це перевірене розгортання вже схваленого дайджесту, а не виключення з процесу.
Operations and Deployment · Розгортання на серверах без встановлення. Агенти
Дивіться: доказ має залишатися актуальним
Схвалення — це певний момент у часі. Після розгортання Watch порівнює кожен робочий дайджест із затвердженим дайджестом для цього сервісу та середовища. Розгортання залишається безагентним — на ваші хости нічого не встановлюється. Спостереження виконує агентська служба Stella Ops, яка читає дайджести образів, що реально працюють на доступних їй демонах Docker. Агентська служба працює у вашій власній інсталяції Stella, а не на ваших хостах, і читає через Docker API.
Дрейф, як це визначає продукт:
“Running Digest не є затвердженим/розгорнутим дайджестом (незатвердженим або зміненим зображенням)”
Середовища, які Stella Ops не може спостерігати, показані як недоведені і ніколи не вважаються здоровими.
Одиниця, яку спостерігає Watch, — це контейнер, визначений за дайджестом образу, тож виявлення дрейфу покриває контейнеризовані навантаження на ваших хостах, чи то Docker через SSH, Compose або демон Windows.
Межа, названа прямо: те, що працює поза контейнером, перебуває поза доказом Watch. Файли, служби чи виконувані файли, розгорнуті на голому хості, несуть доказ розгортання — хто, що, коли й з якого релізу, ідентифікованого дайджестом, — але не перевіряються безперервно за дайджестом образу.
Детальніше
З чим пов'язана Stella Ops Огляд архітектури Що отримують аудитори