Често задавани въпроси

Не, и това е замисълът, а не ограничение. Docker Compose, Swarm, хостовете по SSH/WinRM и целите със скриптове са пълноправни цели, а не резервен вариант за онези, които още не са преминали към Kubernetes.

Поддържани цели: проекти с Docker Compose, хостове по SSH/WinRM. Разгръщанията по SSH/WinRM са без агенти — работата се извършва от образа на Docker.

Обратното също важи: ако всичко при вас работи върху Kubernetes, Stella Ops не е вашият инструмент. Изградена е за другата половина от инфраструктурата — виртуални машини, Compose проекти, класически сървъри — а повечето екипи имат и двете.

Липсата се показва като Missing. Не като успешна проверка, не като предполагаемо изправно състояние и не като тихо пропускане.

Всеки етап от веригата за проследимост е в едно от три състояния — Missing, Recorded или Signed. Контролна точка, която не намира нужните ѝ доказателства, не приема проверката за успешна по подразбиране; NOT EVALUATED никога не се брои за успешна проверка. Повечето инструменти приемат липсата на доказателства за липса на проблем. Тук е точно обратното и именно затова останалите доказателства имат стойност.

Да. Примерната капсула е истински подписан архив, който можете да проверите със стандартни инструменти — cosign verify-blob и sha256sum, без никакво участие на Stella Ops.

Този архив е обезличен образец, подписан с демонстрационен ключ, така че не доказва нищо отвъд самия себе си. stella evidence card verify и детерминистичното възпроизвеждане изискват инсталация и капсула, експортирана от продукта — върху образеца те няма да успеят.

Да, и офлайн. Вердиктът се възпроизвежда детерминистично от замразените входни данни, които са го произвели: същия SBOM, същата моментна снимка на бюлетините, същата версия на политиката.

Това е разликата между инструмент, който ви казва отговор, и такъв, който може да бъде накаран да покаже как е стигнал до него месеци по-късно — на машина без мрежа, пред човек, който не ви вярва.

След разгръщането Stella продължава да наблюдава. Наблюдение е последният етап от веригата за проследимост (Изходен код → Компилиране → Сканиране → Вердикт → Решение → Разгръщане → Наблюдение): той сравнява хеша, който действително работи във всяка среда, с хеша, одобрен за нея.

Когато се различават, услугата се отбелязва: работещият хеш не е одобрен или разгърнат хеш (образът е неодобрен или променен). Виждате точно коя услуга, в коя среда се е отклонила от одобреното си състояние.

Услуга, за която Watch няма доказателства, отчита Missing — тя никога не се показва като съвпадаща само защото се предполага, че нищо не се е променило.

Вижте изгледа на инфраструктурата →

Да, и това се налага от самия продукт, а не се оставя на мрежата ви. Запечатаният режим (EgressPolicyMode.Sealed) блокира изходящия трафик; stella offline import --bundle внася подписан комплект; stella evidence verify-offline проверява контролните суми, манифеста, обвързването с DSSE и покритието с плочки (tiles) на Rekor изцяло без мрежа и при всяка следа от подправяне отказва.

Offline Kit включва източници на уязвимости, контейнерни образи и данни за произход. Получавате идентични резултати от сканиране онлайн или в суверенна мрежа.

Вижте Offline Kit →

Графите на извикванията се изграждат чрез конвейера за сканиране за девет езика: на ниво компилатор — за Go, Java и .NET, и от изходния текст — за Python, JavaScript, TypeScript, Rust, PHP и Ruby. Всяко ребро носи нивото на анализа, което го е създало.

По-важен е по-тесният случай: изграждането на граф на извикванията от дърво с изходен код в CLI поддържа само Go и Rust. Всичко останало пристига като граф, предварително извлечен от конвейера. Находките на непокрити езици не се изхвърлят тихомълком — остават в работния набор като неизвестни и получават оценка, вместо да бъдат пропуснати.

Записът на целта никога не съдържа тайната — само препратка към нея. Самата тайна е запечатана с AES-256-GCM под ключ, производен за всеки клиент, а шифроването е обвързано с клиента, собственика и идентичността на данните, така че шифрограмата на един ред не може да се използва като на друг. След това целият запис на връзката към целта се запечатва отново в собствен криптографски домейн, преди да достигне базата данни.

Главният ключ го предоставяте вие; ние никога не генерираме такъв. Идва от променлива на средата, монтиран файл, чиито права се проверяват, HashiCorp Vault или OpenBao, или HSM. Ако не е конфигурирано трайно хранилище, всяко запечатване и всяко разрешаване се провалят, вместо тихо да преминат към паметта.

Ограничаването и подмяната се налагат, а не се препоръчват: всяко търсене се филтрира по клиент, така че четене между клиенти не връща нищо и не разкрива дори съществуването на идентификационни данни. Подмяната запазва предишната тайна разрешима за период на изчакване и след това отказва, а отнемането изтрива запазената шифрограма, така че по-късно компрометиране на ключ не може да я възстанови.

Издание с контролна точка се блокира, а не се подминава. Ако скенерът или машината за политики са недостъпни, контролната точка приема изтичането на времето като неуспех по замисъл — коментарите в кода го казват точно така, а никъде в CLI няма превключвател за fail-open. Същото важи и при разгръщането: артефакт, чийто резултат от сканиране не може да бъде получен, не се разгръща.

Издаването по време на авария е умишлено и отговорно действие, не заобикаляне. Изключението за контролната точка изисква право, което по подразбиране никой не притежава, писмена обосновка, изрично потвърждение на риска, срок между един и 365 дни — безсрочни изключения се отхвърлят — подпис на оператора, който поема отговорността, и повторно удостоверяване през последните пет минути. То се записва към изданието. Обърнете внимание: трябва да се конфигурира предварително — при непроменена инсталация пътят за подписване не е свързан, така че заявката се отхвърля, докато не регистрирате операторски ключ.

Контролната точка не изисква цялата платформа. Решението за разгръщане зависи от около десет услуги — базата данни, оркестратора на издания, скенера, машината за политики, идентичността и шлюза — не от целия набор; запечатването на доказателства, известията и одитът в timeline са извън пътя на решението.

Разгръщането на чиста VM е пълноценно: през SSH, WinRM или Ansible Stella Ops може да постави файл, да рестартира услуга или да изпълни подаден от оператора изпълним файл на хоста, и записва командата, изхода ѝ и кода на изход като доказателство — без контейнер.

Непрекъснатото наблюдение (Watch) има по-тесен обхват и тук си струва да сме точни. Watch и достижимостта наблюдават работещи контейнери по хеш на образа — така засичането на отклонения знае, че работещият артефакт все още съвпада с одобрения. Хост, от който не може да се прочете контейнер, се показва като ненаблюдаван и никога не се приема за изправен. Затова суров процес на хост без Docker се разгръща и изпълнението му се записва, но не се наблюдава непрекъснато за отклонения, както контейнеризирано работно натоварване. „Обикновени сървъри“ означава сървъри, които изпълняват контейнери извън Kubernetes, а не произволни неконтейнеризирани процеси.

Не. Оправомощен оператор сам премахва блокирането. Заявявате ограничено във времето изключение от политиката, което минава през процес на одобрение, конфигуриран от вас: именувани роли на одобряващите, минимален брой одобряващи, код на причина, подкрепящи доказателства и евентуални компенсиращи контроли, с максимален срок на действие. Самоодобрението е превключвател, който задавате вие, а не наложена от нас настройка по подразбиране.

Предоставеното изключение обръща точно тази находка — потискане, отлагане, понижаване или изискване на контрол — и се записва в одитната следа на решението заедно с това кой го е одобрил и кога. Може да се подпише с DSSE, така че освобождаването е отчетно и възпроизводимо, а не тихо заобикаляне, което изчезва от записа.

Един праг остава умишлено неотменим: всеки разгърнат артефакт трябва да има реално преминаване през скенера. Изключението снема конкретна находка на политиката; то никога не снема изискването артефактът изобщо да е бил сканиран.

По подразбиране Stella Ops поддържа собствени локални потребители и хешира паролите с Argon2id. Конекторите за SAML, OIDC и LDAP/Active Directory се доставят подписани заедно с платформата, а включването на някой от тях е стъпка от конфигурацията, която извършва операторът, а не настройка по подразбиране. Инсталационният пакет съдържа конфигурационен файл за всеки конектор.

Достъпът е ограничен по клиент и се основава на права, а не на груби роли. Платформата включва над 200 именувани права, така че важните действия са отделни разрешения: одобряването на изключение от политиката, заобикалянето на контролна точка при издание и подмяната на ключ за шифроване на ключове са отделни права. Можете да дадете на някого възможност да чете находки, без да може да премахва блокиране.

Променящите действия се записват в собствената одитна следа на продукта, със собствено право за четене — отделно от и в допълнение към подписаната верига от доказателства, която носи изданието. Нищо от това не зависи от плана: „Безплатен“ и „Лицензиран“ включват всички възможности.

Това е правилният въпрос и няма да го подминем: подписът доказва, че вашата инсталация е произвела вердикта, така че компрометирана контролна равнина може да подпише запис, който изглежда валиден. Дизайнът прави този запис труден за сляпо доверие и лесен за улавяне.

Проверката се извършва спрямо доверителен корен, който вие конфигурирате, и без такъв отказва — тя никога не се обръща към услуга на Stella Ops, за да реши на какво да се доверява. Всеки вердикт получава времеви печат от посочен от вас орган за удостоверяване на времето, а вписване в журнал за прозрачност е възможно в журнал, който поддържате вие — така „кога“ и „вписано ли е изобщо“ са закотвени извън проверяваната система.

Най-силната проверка е повторното възпроизвеждане: всеки вердикт се преизчислява от запечатаните си входове, а запис, който не се преизчислява до същия резултат, се проваля. Пуснете повторното възпроизвеждане на инфраструктура, която подозираната контролна равнина не контролира, и фалшифициран вердикт не оцелява при преизчислението. Нищо от това не прави компрометираната равнина безобидна — то премества котвата на доверието извън тази равнина и ви дава независим начин да засечете лъжа.

Нищо не е премахнато. Достижимостта променя дали дадена находка блокира придвижване, а не дали съществува: находката остава в записа със състоянието, което ѝ е дадено, а доказателствата на контролната точка записват пълния брой находки редом с подмножеството, което действително е блокирало. Няма стъпка на потискане, която да трябва да се възстановява впоследствие.

Капсулата казва защо и кога. Тя обвързва по хеш всеки вход, довел до вердикта: SBOM, моментните снимки на бюлетините, доказателството за достижимост, от което идва състоянието, и идентификатора и версията на политиката, която е действала върху него. Одобрението, с което изданието е придвижено, се записва към самото издание, на етапа Decision от веригата за проследимост.

И се преизчислява. Възпроизвеждането изпълнява вердикта отново от тези запечатани входни данни в офлайн среда и сравнява резултата със записания, като отчита разминаване, ако се различават; възпроизвеждане, което не може реално да преизчисли, се проваля, вместо да върне запазения вердикт. След инцидент това, което е било известно към момента на решението, е въпрос на запис, а не на спор.

Остатъчният риск е ваш. Вашата политика е решила кои състояния блокират и кои не, а една контролна точка е толкова добра, колкото политиката зад нея. Stella Ops твърди, че решението е подкрепено с доказателства и възпроизводимо; никога не е твърдяла, че е било правилно. Добре е да знаете, преди да напишете тази политика: само доказан достижим път може да блокира издание, защото „няма наблюдаван път“ не е доказателство, че път не съществува, и не се записва като такова.

Доказателства и одит → Как работи достижимостта →

Вердиктът се отваря отново. Актуалността на бюлетините за сигурност не е отчет, който четете по-късно — новите данни от бюлетините преоценяват вече взетите решения, а засегнатото издание се отбелязва.

Решение, което е било правилно във вторник, може да престане да бъде правилно в четвъртък, без нищо във вашата инфраструктура да се е променило. Системите, които оценяват само в момента на придвижване, не могат да видят това.

Възрастта на данните се показва на екрана за всеки източник. Остаряването е видимо и никога не се крие.

Изолирана инсталация, която тихомълком работи с бюлетини отпреди месец и изглежда изправна, е по-лоша от такава, която отказва да стартира. Stella Ops ви показва възрастта на данните, с които взема решения, а импортът на Offline Kit записва хеша на моментната снимка, така че възпроизвеждане месеци по-късно да използва същите данни, с които сте взели решението.

Нещо, което могат да проверят сами, без да ни се доверяват и без да инсталират каквото и да било. Публикуваната примерна капсула се проверява с cosign verify-blob и sha256sum за около трийсет секунди.

• Какво е сканирано (точен хеш на артефакта)
• Какво е намерено (SBOM?Software Bill of Materials – пълен списък на всички пакети и зависимости във вашия софтуер + достижимост)
• Защо е одобрено (решение по политика)
• Кой го е одобрил (подписани одобрения)

Одиторите могат независимо да проверят подписите и да възпроизведат решението офлайн с stella replay.

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

Не. Доказателствата идват от CLI във вече съществуващата ви задача за компилиране. stella ci init създава основата на стъпките в конвейера; CLI подписва доказателствата за компилирането в самата задача (stella attest sign).

Не е необходим конектор — работи всяка CI система, която може да стартира двоичен файл. Stella използва подписани хешове и доказателства, а не достъп до хранилището.

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

Пакетите за съответствие съпоставят доказателствата за проследимост със задълженията по NIS2, DORA и CRA. Активирането започва събиране на доказателства в консервативен режим само за доказателства; то не заявява съответствие с регулаторните изисквания.

Операторът винаги остава регулираният субект, който взема решенията. Stella ви помага да съберете и подпишете артефактите, които регулаторът очаква — продуктът никога не ги подава и никога не сертифицира.

Някои пътища за подаване все още се разработват — например автоматичното подаване към ENISA очаква официалната схема (днес операторът може да използва запис във файловата система). Текущото състояние на всеки пакет е посочено на страницата за съответствие.

Подробна информация за пакетите за съответствие →

Едно управлявано работно натоварване в една среда на вашата инсталация: контейнерна услуга или артефакт, адресиран по хеш и разгърнат на хост през SSH или WinRM; и двата вида се броят еднакво. Връзката „работно натоварване – среда“ може да се брои, когато Stella Ops разгръща, пропуска през контролна точка или придвижва неговите издания, сканира инсталирания му образ или артефакт или прилага към това инсталирано работно натоварване резултат от по-ранно сканиране. Прилагането на по-ранен резултат не изисква ново сканиране. Всяка отговаряща на условията връзка се брои веднъж, дори когато се отнасят няколко от тези дейности.

Разполаганията се броят в рамките на инсталацията — едно логическо разгръщане на контролната равнина на Stella Ops: възлите на клъстера, репликите на базата данни и компонентите за аварийно превключване на едно и също разгръщане се броят заедно, а независимо експлоатираните инсталации са отделни. Собствената инфраструктура на Stella Ops никога не се брои. Разполагането приключва, когато всяко управление на това работно натоварване в тази среда действително приключи или когато натоварването бъде премахнато и никоя друга управленска дейност не го поддържа активно; приключването на сканиране не го прекратява, а съхраняването на исторически доказателства или отчети само по себе си не създава, не възобновява и не поддържа разполагане.

Текущото издание не показва общ брой разполагания. Пребройте всяко работно натоварване във всяка среда по веднъж, ако Stella Ops разгръща, пропуска през контролна точка или придвижва неговите издания, сканира инсталирания му образ или артефакт или прилага към него резултат от по-ранно сканиране. Изгледът Estate изброява разгръщанията, извършени от Stella Ops; длъжни сте да преброите и всички останали отговарящи на условията работни натоварвания, включително разгръщаните от други инструменти и тези, които автоматичният инвентар не показва.

Какво се брои за управлявано разполагане →

Не. Пет реплики на работно натоварване в една среда са едно разполагане. Рестартирането, повторното му разгръщане или пускането на нова версия на образа или нов хеш на същото работно натоварване в същата среда не добавя нищо.

Три. Едно разполагане е едно работно натоварване в една среда, така че работно натоварване, пуснато в dev, staging и production, е 3 разполагания, а десет работни натоварвания в три среди са 30. Самите среди никога не се ограничават и не се таксуват.

Не. Няма такса за сканиране, повторно сканиране, отчет за уязвимости, придвижване или разгръщане. Сканирането на образа или артефакта на инсталирано работно натоварване или прилагането към него на резултат от по-ранно сканиране може да включи това работно натоварване в броя на разполаганията за всяка съответна среда. Всяка връзка „работно натоварване – среда“ се брои само веднъж, независимо от броя на сканиранията или отчетите.

Самото съхраняване или преглеждане на отчет единствено като историческо доказателство не създава разполагане. Представянето на по-ранен резултат като приложима информация от сканиране за инсталирано работно натоварване се счита за прилагане на този резултат. Сканирането на образ или артефакт, който не е инсталиран в никоя от вашите среди, не създава разполагане.

Продукционната употреба над 20 разполагания на инсталация изисква плана „Лицензиран“: лиценз за капацитет за разполагания, не по-малък от броя на разполаганията, които управлявате. Той струва €100 на месец за капацитет до 100 разполагания, а над това — €1 на месец за всяко разполагане от капацитета; над 20 се брои всяко разполагане — безплатните 20 не се приспадат, — така че капацитет от 30 струва €100 на месец, а от 200 — €200.

Увеличенията на капацитета влизат в сила в момента на поръчката и се таксуват пропорционално от тази дата; намаленията влизат в сила при подновяване.

Ако забележите, че по невнимание сте надхвърлили капацитета си или безплатните 20, можете да продължите 14 дни от момента, в който сте забелязали, докато намалите употребата или поръчате капацитет. Този гратисен период е за случайни превишавания, а не за умишлени или повторни.

Можете да се абонирате още днес: пишете на sales@stella-ops.org; поръчката се прави чрез оторизиран търговец (merchant of record). Онлайн плащането ще бъде достъпно скоро.

Колко ще струва? →

„Лицензиран“ има месечен минимум от €100, който покрива до 100 разполагания: и 21, и 100 разполагания струват €100 на месец. От 101 разполагания цената е €1 на разполагане — 101 струват €101, 150 струват €150.

Нищо не се изключва. Текущото издание не налага ограничението за разполагания и не проверява лиценз, така че софтуерът ви, работните натоварвания, сканиранията и разгръщанията продължават да работят, а всеки запис с доказателства остава проверим със собствения ви доверителен корен.

Платеният капацитет обаче е лицензиран за срока на абонамента. След изтичането на срока продукционната употреба над 20 разполагания изисква подновяване или намаляване до 20 разполагания или по-малко.

Не. Няма лицензен сървър, активиране или обаждане „към дома“: текущото издание не проверява лиценз, така че изолирана инсталация е лицензирана точно както свързана. Безплатната ви употреба се определя от условията на лиценза, а платеният капацитет — от поръчката ви, а не от връзка с нас.

Актуализациите на данните за уязвимости достигат до офлайн инсталация чрез Offline Kit, а възрастта на данните се показва на екрана за всеки източник.

Чрез поръчката ви. Планът „Лицензиран“ се купува чрез оторизиран търговец (merchant of record) за капацитет за разполагания, не по-малък от броя на разполаганията, които управлявате, а приетата поръчка посочва този капацитет и срока по Клиентското споразумение на Stella Ops.

Текущото издание не импортира и не проверява този запис, така че поддържането на инсталацията в неговите рамки е ваша отговорност. При изтичане на срока нищо в софтуера не се изключва, но тогава продукционната употреба над 20 разполагания изисква подновяване или намаляване до 20.

Клиентско споразумение →

Доказателствата, които създава вашата инсталация, се подписват с нейните собствени ключове, а не с нашите. Преносим пакет с доказателства се проверява изцяло офлайн спрямо доверителния корен, който посочите: stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>. Командата проверява контролните суми, обвързванията в манифеста и подписа и при всяка неуспешна проверка отказва.

Изданията на Stella Ops се подписват отделно: пакетът на изданието и образите са подписани с Cosign, а публичният ключ е на страницата с ключове за проверка. Подписът на изданието показва, че пакетът е от нас; подписът на доказателството показва, че записът е от вашата инсталация.

Ключове за проверка →

Да, чрез същите интерфейси, които използва човек. CI задача, скрипт или ИИ агент, който пускате, се удостоверява като служебен клиент на OAuth (client credentials) и управлява изданията чрез API за издания или stella release approve|reject|promote|deploy|rollback. Одобренията и контролните точки по политики се оценяват от сървъра, така че към автоматизиран клиент се прилага същата политика като към човек.

Включват се и други скенери: stella sbom upload внася външен SBOM във формат CycloneDX?Отворен стандартен формат за SBOM, използван в цялата индустрия или SPDX?Software Package Data Exchange – друг отворен стандартен формат за SBOM, широко използван в софтуер с отворен код и записва кой инструмент го е създал, а stella gate score batch --sarif прекарва находките в SARIF от друг инструмент през същата контролна точка за издание.

Един преглед обхваща един ясно определен проблем. Инженер анализира изпратената от вас информация и отговаря с писмен инженерен отговор: вероятната причина и препоръчваните от нас коригиращи или диагностични стъпки.

Прегледът не включва неограничени инженерни часове, разработка по поръчка, гарантирано отстраняване или постоянно консултиране и за него няма постоянно ниво на обслужване. Преди да купите, ви даваме ориентировъчен срок за изпълнение; след като получим нужната информация, отговаряме писмено в разумен срок. Преди да поискаме логове, ви обясняваме как да изпратите диагностичните данни сигурно. За да купите преглед, пишете на support@stella-ops.org с кратко описание на проблема.

Ако прегледът покаже, че основният проблем е възпроизводим дефект в поддържано и правилно конфигурирано издание, таксата се възстановява — или, ако предпочитате, се кредитира за бъдещи плащания.

Документацията, диагностиката на Doctor и самостоятелното отстраняване на проблеми са безплатни за всички, а съобщаването на дефект в продукта или на уязвимост в сигурността никога не изисква платен преглед.

Stella Ops е във фаза релиз кандидат (v1.0-RC1).

• Сега: v1.0.0-RC1-20261029 — подписаният пакет и образите са публични и се изтеглят анонимно от get.stella-ops.org и registry.stella-ops.org
• Преди да излезе v1.0: поне двама клиенти в продукционна употреба и замразена публична API повърхност
• v1.0 се очаква на 1 януари 2027 г.
• Кодът е достъпен като source-available по BUSL-1.1
• Непроменено и в двата случая: обратно съвместими формати на доказателствата и детерминистично възпроизвеждане

Как да започнете →

Влизането през директория не е включено по подразбиране. Приставките за LDAP, OIDC и SAML се доставят подписани с v1.0.0-RC1-20261029, а инсталационният пакет съдържа конфигурационен файл за всяка от тях, но Stella Ops не предлага влизане през директория без конфигуриране: насочвате приставката към своята директория и я включвате.

Освен това не е инструмент за Kubernetes — това е съзнателна позиция, а не пропуск. Не сканира за зловреден софтуер и не доставя пакети за съответствие с федералните изисквания на САЩ. Ако някое от тези неща е решаващо изискване за вас, днес друго решение ще ви подхожда повече.

Stella Ops моделира изданията като граф на придвижване (dev → staging → prod). На всяка контролна точка:

• Политиката се оценява спрямо доказателствата на артефакта
• Одобренията се записват с криптографски подписи
• Генерира се Decision Capsule?Подписан, експортируем пакет доказателства, запечатващ всеки вход и изход на решение за издаване за офлайн одит и детерминистично възпроизвеждане за одит

Придвижванията са обвързани с хешовете на артефактите, а не с тагове. Същият хеш = повторно използване на същите доказателства.

Stella Ops се разработва в Европа и се управлява от дружество, регистрирано в България. Нашата собствена инфраструктура — този сайт, регистърът и каналите за обновления — се хоства в Швейцария, за която ЕС е приел решение за адекватно ниво на защита на данните. Във веригата ви за доставки няма доставчик със седалище в САЩ. Пълните данни за оператора са в правното уведомление.

Платформата се хоства самостоятелно, затова вашите артефакти, SBOM и доказателства остават в собствената ви инфраструктура — при необходимост и в изолирана мрежа. Европейската юрисдикция и самостоятелното хостване означават, че единствено вие държите доказателствата за изданията си.

Справедлив въпрос за всичко, което стои по пътя на изданията. Отговорът е заложен в самата архитектура: ежедневната работа никога не зависи от връзка с нас. Продуктът се хоства самостоятелно и работи в изолирана среда; няма лицензен сървър и никаква облачна зависимост от нас, а нищо в текущото издание не проверява лиценз, така че при изтичане на абонамента нищо не се изключва — но тогава продукционната употреба над 20 разполагания изисква подновяване или намаляване до 20.

Доказателствата ви също не се нуждаят от нас. Вердиктите и капсулите се проверяват офлайн — stella replay преизчислява решение от запечатаните му входове без никаква услуга или акаунт на Stella Ops.

Изходният код е достъпен (source-available) по BUSL-1.1: можете да четете, компилирате и коригирате версията, която използвате. Лицензът има и вграден срок — всяка версия преминава към отворен лиценз на своята Change Date, най-късно на 20 януари 2030 г. за текущата версия. Не зависите от нас и за ежедневната работа: stella doctor изпълнява диагностичните проверки на инсталацията, stella doctor export опакова пакет за поддръжка, а stella doctor fix прилага неразрушителни поправки. Кодът е на git.stella-ops.org.

В ежедневната работа продуктът се поддържа сам. Doctor проверява състоянието на стека и връща стъпките за отстраняване на всичко, което открие; в прозорец за поддръжка сам прилага неразрушителни поправки, а разрушителни — само зад контролна точка за одобрение с предварителен преглед (dry-run) и траен одитен запис; в останалите случаи ви дава стъпките за ръчно изпълнение. Освен това е налична и помощ от човек — като платен преглед на един ясно определен проблем, а не като нещо, от което зависи работата на инсталацията ви. Ако процесът ви на закупуване изисква договорни условия за непрекъснатост, уточнете обхвата им с sales@stella-ops.org по време на оценката.

Ключовете за проверка, подписан примерен пакет доказателства и документацията за архитектура и укрепване са публични и събрани на страницата за проверка на доставчика, където е посочена и позицията ни относно сертификациите. Клиентски референции очаквайте скоро — резултатите от вътрешната ни бета. Обхватът на разговорите по надлежна проверка може да се определи по време на оценката.

Проверка на доставчика →

Поръчката, плащането, данъците и фактурирането се обработват от оторизиран търговец (merchant of record) — вижте уведомлението за плащане. Можете да поръчате още днес по имейл: планът „Лицензиран“ — на sales@stella-ops.org, преглед от поддръжката — на support@stella-ops.org. Онлайн плащането ще бъде достъпно скоро.

Продуктът е създаден да работи без заявки за поддръжка: Doctor проверява състоянието на стека и сам прилага неразрушителни поправки в прозорец за поддръжка, като ви дава точните стъпки за всичко, което няма да направи без надзор. Документацията, Doctor и самостоятелното отстраняване на проблеми са безплатни във всеки план. Когато ви трябва инженер, прегледът от поддръжката струва €75 за един ясно определен проблем: преди да купите, получавате ориентировъчен срок за изпълнение, а след това — писмен инженерен отговор, като таксата се възстановява, ако основният проблем се окаже възпроизводим дефект в поддържано и правилно конфигурирано издание. Нито един план не включва постоянно ниво на обслужване. Който и да отговаря, това е инженерният екип, който създава продукта — поддръжката не е възложена на външна фирма.

Stella Ops Suite е с достъпен изходен код (source-available) по BUSL-1.1. Можете да четете, компилирате и одитирате кода. Слоят за проверка (валидиране на капсули и проверка на подписи) е лицензиран под Apache-2.0. Кодът е на git.stella-ops.org.

BUSL-1.1 разрешава безплатна продукционна употреба до 20 управлявани разполагания на инсталация. Над това продукционната употреба изисква плана „Лицензиран“ — лиценз за броя на вашите разполагания. След датата на промяна (Change Date) — четири години след всяко издание — кодът преминава към Apache-2.0.

Този модел финансира устойчиво развитие, като запазва веригата от доказателства напълно одитируема.

Тенантът е изолирано работно пространство със собствени потребители, роли, политики и история на доказателствата. Спирането на тенант замразява целия достъп до него.

Тенантите споделят една инсталация; доказателствата и достъпът са разделени по тенанти. Двете думи отговарят на различни въпроси:

• Средата (Environment?Логическа цел за внедряване (напр. dev, staging, prod), която следи история на изданията, правила за придвижване и политики) е цел за разгръщане — къде работи изданието и коя политика контролира придвижването му.
• Тенантът е граница на достъпа и доказателствата — кой може да вижда и да действа и в чия история на доказателствата попадат данните.

Един тенант обикновено обхваща няколко среди. Нито тенантите, нито средите се таксуват: цената се изчислява по управляваните разполагания в цялата инсталация.

Да. Stella Ops е контролният слой над скенера, който ползвате, и резултатът му има къде да отиде: stella sbom upload приема външен CycloneDX?Отворен стандартен формат за SBOM, използван в цялата индустрия или SPDX?Software Package Data Exchange – друг отворен стандартен формат за SBOM, широко използван в софтуер с отворен код документ и записва кой инструмент го е произвел, а stella gate score batch --sarif прекарва SARIF на който и да е производител през същата контролна точка за издаване като собствените сканирания на Stella Ops.

Върху този списък с находки Stella Ops добавя анализ на достижимост, VEX?Vulnerability Exploitability eXchange – машинно четими изявления дали уязвимостите са реално експлоатируеми във вашия контекст от няколко издатели, контролни точки по политики, съобразени със средата, и подписан експорт на доказателства. Вашият скенер открива CVE; Stella Ops решава кои имат значение и доказва решението.

Достижимостта се изчислява от собственото сканиране на хеша от Stella Ops. Импортираният SARIF носи достижимостта, която създателят му е записал — Stella Ops чете това поле, а не я извежда наново.

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

Сравнение с Trivy · Сравнение със Snyk · Пълно сравнение →

Stella Ops не е слой над вашия инструмент за разгръщане — Stella Ops е оркестратор на издания. Docker, Compose, SSH, WinRM, ECS, Nomad и Ansible са вградени изпълнителни приставки. На целите, които те покриват, Stella Ops извършва разгръщането сама и не служи като обвивка на инструмент, който вече го прави.

Вашата система за непрекъсната интеграция остава точно където е, защото контролната точка е просто изпълним файл. Всяка такава система, която може да го стартира, извиква stella gate evaluate и действа според кода на завършване. stella ci init генерира готови конфигурации за GitHub Actions, GitLab CI и Gitea Actions; всяка друга система се свързва ръчно с няколко реда.

Има конектори за Gitea, GitHub App, GitLab, Jenkins, Harbor, Nexus, OCI?Open Container Initiative — индустриалният стандарт за формати на контейнерни образи и регистри регистри, Vault и Consul. Практическото разделение: запазете системата си за непрекъсната интеграция и решете за всяка среда дали Stella Ops извършва разгръщането, или пропуска през контролна точка разгръщане, което извършва вашият инструмент.

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

Сравнение с Octopus Deploy · Какво се свързва и какво не изисква конектор →

Да. Stella Ops дава доказателството на ниво артефакт, на което една програма за съответствие се позовава, но не може да произведе сама: за всяко издание — какво е разгърнато, под кой хеш, през коя политика е минало, кой го е одобрил и на коя дата. Записът се чете от самото разгръщане и се изчислява наново от същите доказателства със същия резултат — отговорът след година е същият като днешния.

Този запис се изнася като осем подписани профила, насочени към регулатора: декларация за приложимост и отчет за ефективност по NIS2; регистър на информацията, отчет за голям инцидент, обмен на информация по член 45 и пакет доказателства за изпитания по DORA; техническо досие и досие за съответствие по CRA. Всеки пакет е запечатан, подписан и проверим офлайн спрямо публикувани доверителни корени — подписът се сверява без никакъв достъп до вашата инсталация на Stella Ops.

Нищо в програмата, която вече поддържате, не се налага да се променя. Всеки експорт е преносим подписан файл: приложете го към контрола, който доказва, дайте го на одитор или го изтеглете през приложния интерфейс за изнасяне на доказателства. А преди изнасянето проверка за готовност назовава за всеки профил какво още липсва — пропускът излиза наяве, докато още можете да го затворите, а не по време на одита.

Полето на съответствието, с източници · Пакетите за съответствие в подробности →