Часто задаваемые вопросы

Нет, и это принцип, а не ограничение. 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 — он никогда не показывается как совпадающий лишь на основании предположения, что ничего не изменилось.

Посмотреть представление 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 использует подписанные дайджесты и доказательства, а не доступ к репозиторию.

Команды, как показано в консоли продукта (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, широко используемый в 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 года
• Исходный код доступен по лицензии BUSL-1.1 (source-available)
• Неизменно в любом случае: обратно совместимые форматы доказательств и детерминированное воспроизведение

Как начать работу →

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

Это также не инструмент для Kubernetes — и это осознанная позиция, а не пробел. Stella Ops не ищет вредоносное ПО и не поставляет пакеты соответствия федеральным требованиям США. Если что-то из этого для вас решающее требование, сегодня вам лучше подойдёт другое решение.

Stella моделирует релизы как граф продвижения (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 на этапе оценки.

Ключи проверки, подписанный пример доказательства, а также документация по архитектуре и усилению защиты общедоступны и собраны на странице проверки безопасности поставщика, где указана и наша позиция по сертификации. Отзывы клиентов появятся позже — по результатам нашего внутреннего бета-тестирования. Объём комплексной проверки (due diligence) можно согласовать на этапе оценки.

Проверка безопасности поставщика →

Заказ, оплату, налоги и выставление счетов обрабатывает уполномоченный продавец по документам (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 — это управляющий слой поверх любого сканера, который вы используете, и его результатам есть куда поступать: stella sbom upload принимает внешний документ CycloneDX?Открытый стандартный формат для SBOM, используемый во всей отрасли или SPDX?Software Package Data Exchange – ещё один открытый формат для SBOM, широко используемый в open source и записывает, какой инструмент его создал, а stella gate score batch --sarif пропускает SARIF от любого инструмента через тот же гейт релиза, что и собственные сканирования Stella.

Поверх этого списка находок Stella добавляет анализ достижимости, VEX?Vulnerability Exploitability eXchange – машиночитаемые утверждения о том, являются ли уязвимости реально эксплуатируемыми в вашем контексте от нескольких издателей, гейты политик с учётом среды и экспорт подписанных доказательств. Ваш сканер находит CVE; Stella решает, какие из них важны, и доказывает это решение.

Достижимость вычисляется собственным сканированием дайджеста в Stella. Импортированный SARIF несёт ту достижимость, которую записал создавший его инструмент, — Stella читает это поле, но не выводит его заново.

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

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

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

Ваша система 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 или пропускает через гейт развёртывание, которое выполняет ваш нынешний инструмент.

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

Сравнение с Octopus Deploy · Что подключается, а что не требует коннектора →

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

Эта запись выгружается восемью подписанными профилями для регулятора: декларация применимости и отчёт об эффективности по NIS2; реестр информации, отчёт о крупном ИКТ-инциденте, обмен информацией по статье 45 и пакет доказательств TLPT по DORA; техническое досье и досье соответствия по CRA. Каждый пакет запечатан, подписан и проверяется офлайн по опубликованным корням доверия — подпись сверяют без какого-либо доступа к вашей установке Stella.

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

Обзор рынка средств соответствия — с источниками · Пакеты соответствия подробно →