От хеша на артефакта до живо доказателство
Всяко издание преминава по една последователност. Всеки етап съдържа доказателства, свързани с хеша на артефакта, и е точно в едно състояние: MISSING, RECORDED или SIGNED. След разгръщането Наблюдение продължава да проверява дали доказателството остава валидно.
След първоначалната настройка ще имате:
- 1. Първия си образ, сканиран със
SBOMSoftware Bill of Materials – пълен списък на всички пакети и зависимости във вашия софтуер+ анализ по достижимост - 2. Подписана
Decision CapsuleПодписан, експортируем пакет доказателства, запечатващ всеки вход и изход на решение за издаване за офлайн одит и детерминистично възпроизвеждане, която доказва резултатите от сканирането - 3. Едно пълно придвижване от dev към staging с доказателства
Къде се вписва Stella Ops
Stella Ops стои между вашето CI и сървърите ви. CI изгражда образи. Stella Ops решава дали могат да бъдат промотирани, внедрява ги на цели извън Kubernetes (Compose, SSH/WinRM) и експортира доказателства за одит.
Gate от всяка CI/CD система
Каквото и да изпълнява вашите внедрявания — Jenkins, стъпки в Octopus, GitLab CI, GitHub Actions, шел скрипт на билд машина — контролът минава през Stella по един и същи начин: добавете етап, който изпълнява CLI.
Командата излиза с ненулев код, когато контролът блокира, така че етапът се проваля и конвейерът спира. Няма какво друго да се свързва: без входящ webhook, без 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 г.).
$ stella gate evaluate --env staging --image sha256:8c1a4f…
Командите са показани както в продуктовата конзола (v1.0-RC1).
Проверка, която не е могла да се изпълни, се отчита като NOT EVALUATED и се записва във вердикта. Никога не се отчита като успешна.
Какво блокира доставянето — първо достижимата, некоригирана и значима за политиката експозиция. Останалите са на един филтър разстояние.
Всяка неуспешна проверка посочва задействаното правило, прочетеното доказателство и находката зад него. Отговорът е във вердикта — не в повторно стартиране на скенери или кореспонденция с екипа по сигурност. „Защо изданието ми е блокирано?“ →
Ако Stella Ops е недостъпна, портата блокира.
Изтичане на времето на скенера или на policy engine се третира като отказ по замисъл, а не се пропуска; в CLI няма никакъв fail-open флаг. Артефакт, чийто резултат от сканиране не може да бъде извлечен, не се разгръща.
Издаване по време на авария е съзнателен и подотчетен акт, а не заобикаляне: подписано, ограничено и срочно изключение, записано на оператора, който го е поел, и конфигурирано преди първата употреба.
Опорни доказателствени точки
Всяко твърдение сочи към проверими доказателствени артефакти, работен поток за възпроизвеждане и спецификационна документация.
Връзки към доказателства и методология: Доказателства и одит | Спецификация на Decision Capsule | Операции и разгръщане
Разгръщане: одобрени хешове към цели без Kubernetes
Етапът Разгръщане разгръща одобрения хеш и записва какво къде е доставено. Целите са инфраструктурите, които повечето инструменти за издания пренебрегват.
- → Проекти с Docker Compose
- → Хостове по SSH/WinRM — без агенти по замисъл
- → Поетапни, канареечни и синьо-зелени стратегии
- → Връщането назад насочва към известен надежден хеш, за който доказателствата вече са записани
- → Всяко разгръщане записва хеша, средата и времето
Връщането назад е проверено разгръщане на вече одобрен digest, не изключение от процеса.
Операции и разгръщане · Деплойвайте към сървъри без инсталиране на агенти
Наблюдение: доказателството трябва да остане валидно
Одобрението е момент във времето. След разгръщането Watch сравнява всеки работещ хеш с одобрения хеш за съответната услуга и среда. Разгръщането остава без агенти — на вашите хостове не се инсталира нищо. Наблюдението се извършва от агентската услуга на Stella Ops, която чете дайджестите на образите, реално работещи на Docker демоните, до които има достъп. Агентската услуга работи във вашата собствена инсталация на Stella, а не на хостовете ви, и чете през Docker API.
Отклонение според определението на продукта:
“работещият хеш не е одобрен или разгърнат хеш (образът е неодобрен или променен)”
Средите, които Stella не може да наблюдава, се показват като недоказани и никога не се приемат за изправни по подразбиране.
Единицата, която Watch наблюдава, е контейнерът, идентифициран по дайджест на образа — така засичането на отклонение покрива контейнеризирани товари на вашите хостове, независимо дали работят върху Docker през SSH, Compose или Windows демон.
Границата, казана ясно: това, което работи извън контейнер, е извън доказателството на Watch. Файлове, услуги или изпълними файлове, разположени на гол хост, носят доказателство за разгръщането — кой какво е разгърнал, кога и от кое издание, идентифицирано по хеш — но не се проверяват непрекъснато по хеш на образа.
Научете повече
Към какво се свързва Stella Преглед на архитектурата Какво получават одиторите