Поширені запитання

Ні, і це принцип, а не обмеження. 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 Ops продовжує спостереження. Watch — останній етап магістралі збереження доказів (Source → Build → Scan → Verdict → Decision → Deploy → Watch): він порівнює дайджест образу, фактично запущеного в кожному середовищі, зі схваленим для цього середовища дайджестом.

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

Сервіс, для якого Watch не має доказів, отримує статус Missing — його ніколи не показують як такий, що збігається, лише з припущення, що нічого не змінилося.

Переглянути подання Estate →

Так, і це забезпечує сам продукт, а не налаштування вашої мережі. Запечатаний режим (EgressPolicyMode.Sealed) блокує вихідний трафік; stella offline import --bundle імпортує підписаний комплект; stella evidence verify-offline перевіряє контрольні суми, маніфест, прив'язку DSSE і покриття тайлів 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 лежать поза шляхом рішення.

Розгортання на чисту ВМ повноцінне: через 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 Ops приймає підписані дайджести й докази, а не доступ до репозиторію.

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

Пакети відповідності зіставляють докази ланцюга збереження з вимогами NIS2, DORA і CRA. Увімкнення запускає збирання доказів у консервативному режимі лише доказів; це не є заявою про відповідність нормативним вимогам.

Оператор завжди залишається суб'єктом прийняття рішень, на якого поширюється регулювання. Stella Ops допомагає зібрати й підписати артефакти, яких очікує регулятор, але ніколи не подає їх і не сертифікує відповідність.

Деякі шляхи запису ще в розробці — наприклад, автоматичне надсилання до 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, широко використовуваний в open source і фіксує, яким інструментом його створено, а 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 не шукає шкідливе ПЗ і не постачає пакети відповідності федеральним вимогам США. Якщо щось із цього для вас вирішальна вимога, сьогодні вам краще підійде інше рішення.

Stella Ops моделює релізи як граф просування (Dev → Stage → Prod). На кожній контрольній точці:

• Політика оцінюється за доказами артефакту
• Схвалення записуються з криптографічними підписами
• Генерується Decision Capsule?Підписаний експортований пакет доказів, що запечатує всі вхідні та вихідні дані рішення про реліз для офлайн-аудиту та детермінованого відтворення для аудиту

Просування прив'язані до хешів артефактів, а не до тегів. Той самий хеш = ті самі докази, використані повторно.

Stella Ops розробляється в Європі, а її оператором є компанія, зареєстрована в Болгарії. Наша власна інфраструктура — цей сайт, реєстр і канали оновлень — розміщена у Швейцарії, щодо якої діє рішення ЄС про адекватність захисту даних. У вашому ланцюжку постачання немає постачальника зі штаб-квартирою у США. Повні відомості про оператора наведено в правовому повідомленні.

Платформа розгортається у вашій інфраструктурі, тому артефакти, SBOM і докази залишаються у вас — за потреби в ізольованій мережі. Європейська юрисдикція та самостійне розгортання означають, що докази ваших релізів зберігаєте лише ви.

Слушне питання для всього, що стоїть на шляху релізу. Відповідь закладено в саму архітектуру: щоденна робота ніколи не залежить від зв'язку з нами. Продукт розгортається у вашій інфраструктурі й працює в ізольованому середовищі; немає ні сервера ліцензій, ні хмарної залежності від нас, і ніщо в поточному випуску не перевіряє ліцензію, тож після завершення підписки нічого не вимикається — але використання у продуктивному середовищі понад 20 розміщень тоді потребує поновлення підписки або скорочення до 20.

Ваші докази теж нас не потребують. Вердикти й капсули перевіряються офлайн — stella replay переобчислює рішення з його запечатаних вхідних даних без жодного сервісу чи облікового запису Stella Ops.

Вихідний код доступний за ліцензією BUSL-1.1 (source-available): ви можете читати, збирати й латати версію, якою користуєтеся. Ліцензія має і вбудований термін — кожна версія переходить на відкриту ліцензію у свою 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 має доступний вихідний код за 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, широко використовуваний в open source і записує, який інструмент його створив, а 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 виконує розгортання сама і не огортає засіб, що вже це робить.

Ваша система CI залишається там, де є, бо гейт — це просто виконуваний файл. Будь-яка система CI, здатна його запустити, викликає stella gate evaluate і діє за кодом завершення. stella ci init створює готові конфігурації конвеєрів для GitHub Actions, GitLab CI і Gitea Actions; будь-яку іншу систему CI підключають вручну кількома рядками.

Є з'єднувачі для Gitea, GitHub App, GitLab, Jenkins, Harbor, Nexus, реєстрів OCI?Open Container Initiative — галузевий стандарт форматів образів контейнерів та реєстрів, Vault і Consul. Тож на практиці поділ такий: залиште свою систему CI і для кожного середовища вирішіть, чи Stella Ops виконує розгортання сама, чи пропускає через гейт розгортання, яке виконує ваш наявний засіб.

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

Порівняння з Octopus Deploy · Що підключається, а що не потребує з'єднувача →

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

Цей запис вивантажується вісьмома підписаними профілями для регулятора: декларація застосовності та звіт про ефективність за NIS2; реєстр інформації, звіт про великий інцидент, обмін інформацією за статтею 45 і пакет свідчень випробувань за DORA; технічне досьє та досьє відповідності за CRA. Кожен пакет запечатаний, підписаний і перевіряється офлайн за опублікованими коренями довіри — підпис звіряють без жодного доступу до вашої інсталяції Stella Ops.

Нічого в програмі, яку ви вже ведете, змінювати не потрібно. Кожне вивантаження — переносний підписаний файл: додайте його до контролю, який він підтверджує, передайте аудиторові або заберіть через програмний інтерфейс вивантаження доказів. А перед вивантаженням перевірка готовності називає для кожного профілю, чого ще бракує, — прогалина спливає, доки ви ще можете її закрити, а не під час перевірки.

Поле відповідності, з джерелами · Пакети відповідності докладно →