常见问题
评估 Stella Ops Suite 用于发布编排和证据级发布的团队常见问题。
快速解答
我需要 Kubernetes 吗?
不需要。Stella Ops 将非 Kubernetes 环境作为主要使用场景设计。
支持的目标:Docker Compose 项目、SSH/WinRM 主机。SSH/WinRM 部署是无代理的——Docker 镜像完成了工作。
反过来也成立:如果你运行的一切都在 Kubernetes 上,Stella Ops 不是你的工具。它为资产的另一半而建——虚拟机、Compose 项目、普通服务器——而多数团队两者都有。
What happens when the evidence is missing?
It is shown as Missing. Not passed, not assumed healthy, not quietly skipped.
Every stage of the custody spine carries one of three states — Missing, Recorded, or Signed. A gate that cannot find the evidence it needs does not fall back to a pass; NOT EVALUATED is never counted as a pass. Most tools treat absence as absence of a problem. This is the opposite of that, and it is the reason the rest of the evidence is worth anything.
Can I verify a Decision Capsule without installing Stella Ops?
Yes. The example capsule is a real signed archive you can check with stock tooling — cosign verify-blob plus sha256sum, no Stella Ops anywhere.
That download is a sanitized sample signed with a demo key, so it carries no trust beyond itself. stella evidence card verify and deterministic replay need an installation and a product-exported capsule — they will not succeed against the sample.
What if I do not trust a verdict — can I re-run it?
Yes, and offline. A verdict replays deterministically from the frozen inputs that produced it: the same SBOM, the same advisory snapshot, the same policy version.
This is the difference between a tool that tells you an answer and one that can be made to show its working months later, on a machine with no network, in front of someone who does not trust you.
什么是漂移检测?
部署后,Stella继续观察。Watch是证据保全链主干的最后一阶段(来源→Build → Scan→评决→Decision → Deploy →Watch):它比较在每个环境中实际运行的摘要与批准的摘要。
当它们存在差异时,服务会被标记:运行摘要不是批准/部署的摘要(未经批准或修改的映像)。你能清楚地看到哪种服务、在哪个环境下偏离了其批准状态。
Watch 没有证据的服务会报告 Missing——绝不会因为假定没有变化就显示为一致。
运维
Stella Ops 能在隔离环境中运行吗?
Which languages does reachability actually cover?
Call graphs are built through the scan pipeline for nine languages: compiler-grade for Go, Java and .NET, and from source text for Python, JavaScript, TypeScript, Rust, PHP and Ruby. Every edge carries the tier that produced it.
The narrower case matters more: building a call graph from a source tree in the CLI supports Go and Rust only. Everything else arrives as a pre-extracted graph from the pipeline. Findings outside covered languages are not silently dropped — they stay in the working set as unknowns, scored rather than skipped.
无代理部署意味着控制平面持有我服务器的凭据。它们如何存储、隔离和轮换?
目标记录从不保存密文本身,只保存指向它的引用。密钥本身以 AES-256-GCM 封存于按租户派生的密钥之下,且加密绑定租户、拥有者与凭据身份,因此一行的密文无法被当作另一行重放。随后整条目标连接记录会在自己的密码域中再次封存,然后才写入数据库。
主密钥由你提供,我们从不生成。它可以来自环境变量、经权限校验的挂载文件、HashiCorp Vault 或 OpenBao,或 HSM。若未配置持久化存储,所有封存与解析都会失败,而不会静默退回内存。
隔离与轮换是强制的,而非建议:每次查询都按租户过滤,跨租户读取返回空,甚至不泄露凭据是否存在。轮换在宽限窗口内保留旧密钥可解析,随后即失败关闭;吊销会擦除已存密文,使日后密钥泄露也无法恢复。
当 Stella Ops 自身宕机时,我的部署会怎样?
受门禁管控的发布会被拦下,而不是被放行。如果扫描器或策略引擎无法访问,门禁按设计将超时视为失败——代码注释就是这么写的,而且 CLI 中任何位置都没有 fail-open 开关。部署时同理:无法取回扫描结果的制品不会被部署。
在故障期间发布是一次有意且可问责的行为,而不是绕过。门禁例外需要一项默认无人持有的权限、书面理由、明确的风险确认、介于 1 到 365 天之间的有效期(无期限的例外会被拒绝)、承担责任的操作者签名,以及最近五分钟内的重新认证。它会记录在该发布上。请注意它需要先行配置:在未修改的安装中签名通路并未接通,因此在你登记操作者密钥之前,请求会被拒绝。
门禁并不需要整个平台。一次部署决策依赖约十个服务——数据库、发布编排器、扫描器、策略引擎、身份与网关——而不是整套产品;证据封存、通知与时间线审计都不在决策通路上。
我们部署到没有 Docker 的普通虚拟机。Watch 在那里覆盖什么?
部署到裸虚拟机是一等能力:通过 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 主张的是该决策有证据支撑且可重放,从未主张该决策是正确的。在编写该策略之前值得知道:只有已证实的可达路径才能阻断发布,因为「未观察到路径」并不能证明路径不存在,也不会被这样记录。
A CVE lands after I already promoted. What happens?
The verdict re-opens. Advisory freshness is not a report you read later — new advisory data re-evaluates decisions that were already made, and the affected release is flagged.
The decision that was correct on Tuesday can stop being correct on Thursday without anything in your estate changing. Systems that only evaluate at promotion time cannot see that.
If I am offline for a month, how do I know the data is stale?
Feed age is reported per source, on screen. Staleness is visible, never hidden.
An air-gapped install that quietly serves month-old advisory data while looking healthy is worse than one that refuses to start. Stella Ops shows you the age of what it is deciding with, and an offline kit import records the snapshot digest so a replay months later uses the same data you decided on.
审计员能得到什么?
审计员会收到Decision Capsules——加密签名的证据包,证明:
- 扫描了什么(确切的工件摘要)
- 发现了什么(
SBOM软件物料清单 - 软件中所有软件包和依赖项的完整列表+ 可达性) - 为什么批准(策略判定)
- 谁批准的(签名的审批)
审计员可以独立验证签名,并使用 stella replay 离线重放决策。
产品控制台显示的命令(v1.0-RC1)。
我需要SCM还是CI连接器?
不。证据来自你现有构建作业中的CLI。stella ci init 是流水线步骤的支架;CLI在作业中签署构建证据(stella attest sign)。
不需要连接器——任何能运行二进制的配置项都能正常运行。Stella消费的是签名摘要和证据,而不是存储库访问。
产品控制台显示的命令(v1.0-RC1)。
Stella Ops对NIS2、DORA还是CRA有帮助?
合规包将证据保全链中的证据映射到 NIS2、DORA 和 CRA 义务。启用后会以保守的纯证据模式开始收集证据;这并不表示符合监管要求。
操作员始终是受监管的决策者。Stella帮助你组装和签署监管机构期望的制品——它从不提交文件,也从不认证。
部分写入路径仍在进行中——例如,ENISA的自动提交传输正在等待官方模式(当前操作员文件系统弃用)。每个背包的当前状态会在合规页面上说明。
商业
预订到底买到了什么?
比你支付的层级更多——目前如此。预订 Plus,即按 Pro 开通:100 个环境而非 20 个,无扫描上限而非每月 50,000 次,持续漏洞数据而非每日更新,以及 Pro 的支持——每年 30 张工单、目标响应 1 个工作日,而非 Plus 的 10 张与 3 个工作日——价格按 Plus 计。此早期采用价到 v1.0 截止;在此之前下单即可保留。除此之外,预订购买的方案与本页所列完全一致,且 RC1 今日已公开,你可以先运行软件再作承诺。订购、付款与开票由授权登记卖方处理;下单时请与销售确认该升级的期限。
Stella Ops 的价格是多少?
免费层级价格为 $0:3 个环境,每滚动 24 小时 100 次新摘要扫描,并包含全部功能。付费层级增加环境数和扫描量:
- Plus — 每月 $499:20 个环境
- Pro — 每月 $1,299:100 个环境
- Enterprise — 定制:协商确定环境数、扫描量和 SLA
Plus 可购买附加包:$399 增加 10,000 次新摘要深度扫描。
所有能力都在每个层级——合规包没有分层门槛。年度账单:按11个月付款,12。
Prices are shown excluding VAT. Any applicable VAT or sales tax is determined and charged at checkout by the merchant of record handling your order, based on your location and tax status.
Stella Ops 是否已准备好用于生产?
Stella Ops 处于候选发布阶段(v1.0-RC1)。
- 现在:v1.0.0-RC1——已签名 bundle 与镜像均为公开,可从 get.stella-ops.org 与 registry.stella-ops.org 匿名获取
- v1.0 发布之前:至少两家客户在生产中运行,且公共 API 表面冻结
- 在 v1.0(预计 2027 年 1 月 1 日):早期采用者预订价结束。在此之前预订持续开放
- 代码在 BUSL-1.1 下源代码公开
- 无论如何都不变:向下兼容的证据格式与确定性重放
What does Stella Ops not do?
Directory sign-in is not on by default. The LDAP, OIDC and SAML plugins ship signed with v1.0.0-RC1 and the install bundle carries a configuration file for each, but Stella Ops does not offer zero-configuration directory sign-in: you point a plugin at your directory and enable it.
It is also not a Kubernetes tool — that is a deliberate position, not a gap. It does not scan for malware, and it does not ship US federal compliance packs. If any of those is your deciding requirement, something else fits better today.
发布和审批是如何工作的?
Stella 将发布建模为发布图(Dev → Stage → Prod)。在每个关卡:
- 根据工件的证据评估策略
- 审批使用加密签名记录
- 为审计生成
Decision Capsule签名的可导出证据包,封装发布决策的每个输入和输出,用于离线审计和确定性重放
发布与工件摘要绑定,而非标签。相同摘要 = 相同证据重用。
Stella Ops在哪里?
Stella Ops 在欧洲开发,由一家在保加利亚注册的公司运营;我们自己的基础设施——本网站、镜像仓库和更新通道——托管在瑞士,瑞士已获得欧盟数据保护充分性认定。您的供应链中没有总部位于美国的供应商。完整的运营方信息见法律声明。
该平台是自托管的,因此你的文件、SBOM和证据都保存在你自己的基础设施上——如果需要,可以进行空中隔离。欧洲管辖权加上自托管意味着只有你自己持有你的发布证据。
Stella Ops 是单一所有者公司。如果这个人无法联系,会怎样?
对发布路径中的任何组件,这都是合理的问题。设计层面的回答:日常运行从不依赖联系我们。产品自托管、可在隔离网络运行;没有许可证服务器,也不依赖我们的云。
你的证据同样不需要我们。裁决与胶囊可离线验证——stella replay 从密封输入重新计算决策,全程不涉及任何 Stella Ops 服务或账户。
代码在 BUSL-1.1 下源代码公开:你可以阅读、构建并修补所运行的版本。许可证还内置了期限——每个版本在其 Change Date 转为开放许可证,当前版本最迟 2030 年 1 月 20 日。日常运维你也不依赖我们:stella doctor 运行安装的诊断检查,stella doctor export 打包用于支持的诊断包,stella doctor fix 应用非破坏性修复。源码位于 git.stella-ops.org。
日常运行中,产品自己照顾自己。Doctor 会对整个栈做健康检查,并针对发现的每一项返回修复步骤;在维护窗口内它自行执行非破坏性修复,破坏性操作则必须经过审批门禁,并附带空跑预览与持久审计记录——否则它把手工步骤交给你。人工支持是在此之上的付费附加项,而不是维持你安装环境运行的前提。如果贵司采购需要合同层面的连续性条款,请在评估期间与 sales@stella-ops.org 商定。
采购
供应商审查可获得哪些安全文档?
验证密钥、已签名的证据示例以及架构和加固文档均已公开,汇总在供应商安全审查页面上,该页面同时说明了我们的认证态势。客户参考案例即将推出——来自我们内部测试版的结果。尽职调查的讨论范围可在评估期间确定。
订购与发票如何处理?
订购、付款、税费与发票由授权登记卖方处理——参见结账说明。其余事项请在评估期间联系 sales@stella-ops.org。
每个方案包含哪些支持?是否提供企业级 SLA?
产品的设计目标是无需工单也能持续运行:Doctor 会对整个栈做健康检查,并在维护窗口内自行执行非破坏性修复,对于不会无人值守执行的项目则把确切步骤交给你。此外:Free 与 Plus 为自助——文档、社区讨论与 Doctor 诊断,无合同响应目标。Pro 增加邮件支持渠道,响应目标为 1 个工作日。企业支持及其响应与引导条款按合同约定,评估期间与 sales@stella-ops.org 商定。无论由谁回复,都是打造产品的工程团队——支持不外包。
许可和兼容性
Stella Ops 是开源的吗?
Stella Ops Suite 以按 BUSL-1.1 源码可用方式提供。您可以阅读、构建和审计代码。验证层(胶囊验证和签名检查)按 Apache-2.0 许可。源码位于 git.stella-ops.org。
BUSL-1.1 允许在免费限制内用于生产(3 个环境,每个滚动 24 小时内 100 次新摘要扫描)。超出限制则需要付费方案。每个版本发布四年后的变更日期起,代码转为 Apache-2.0。
此模型为可持续发展提供资金,同时保持证据链完全可审计。
What is a tenant, and how is it different from an environment?
A tenant is an isolated workspace with its own users, roles, policies, and evidence history. Suspending a tenant freezes all of its access.
Tenants share an installation; evidence and access are separated per tenant. The two words answer different questions:
- An
Environment逻辑部署目标(例如dev、staging、prod),跟踪自己的发布历史、晋级规则和策略门控is a deployment target — where a release runs, and what policy gates its promotion. - A tenant is an access and evidence boundary — who can see and act, and whose evidence history it lands in.
One tenant normally holds several environments. Tenants are not metered: tiers meter environments and new-digest scans.
What consumes a new-digest deep scan?
A new-digest deep scan is consumed when Stella analyses a container digest for the first time and produces SBOM软件物料清单 - 软件中所有软件包和依赖项的完整列表, vulnerability, and reachability evidence. Only unique digests count.
Consumes one deep scan:
- The first scan of a new artifact digest
Does not consume a deep scan:
- Re-deploying an already-scanned digest
- Promoting an already-scanned digest
- Re-evaluation when
CVE公共漏洞和暴露 - 公开已知安全漏洞的唯一标识符or advisory intelligence updates - Querying existing Decision Capsules
Plus 按自然月计量:配额在每月 1 日重置,因此月内出现峰值没有问题。Pro 扫描不限量。免费层级根本没有重置时刻——许可证允许在任意滚动 24 小时窗口内进行 100 次新摘要深度扫描,也就是说一次扫描在运行 24 小时后不再计入。免费层级不设月度额度池。
If a release spike, migration, or intake window exceeds the monthly quota, a capacity add-on of +10,000 new-digest deep scans is available on Plus for $399.
免费层级是否支持生产使用?
免费套餐允许有限的生产使用:所有功能,最多支持3环境,每滚动 24 小时 100 次新摘要扫描。
超出免费限制的生产需要付费套餐——Plus(20环境)、Pro(100)或更远的Enterprise。
我可以将 Stella 与 Trivy、Snyk 或其他漏洞扫描器一起使用吗?
可以。Stella 是您所用扫描器之上的控制层,其输出都有落点:stella sbom upload 接收外部的 CycloneDX业界广泛使用的软件物料清单(SBOM)开放标准格式 或 SPDX软件包数据交换 - 另一种广泛用于开源的SBOM开放标准格式 文档并记录生成它的工具,stella gate score batch --sarif 则让任何产出方的 SARIF 走与 Stella 自身扫描相同的发布关卡。
在这份发现清单之上,Stella 加上可达性分析、多签发方 VEX漏洞可利用性交换 - 关于漏洞是否在您的上下文中实际可利用的机器可读声明、按环境区分的策略关卡,以及签名证据导出。您的扫描器找出 CVE;Stella 判定哪些真正重要,并为该判定提供证明。
可达性由 Stella 自己对该摘要的扫描计算得出。导入的 SARIF 携带的是其产出方写入的可达性值——Stella 读取该字段,并不重新推导。
产品控制台显示的命令(v1.0-RC1)。
我可以将 Stella 与 Octopus Deploy、Ansible 或其他部署工具一起使用吗?
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开放容器计划 — 容器镜像格式和注册中心的行业标准 镜像仓库、Vault 和 Consul。实际的分工是:保留现有的 CI,再按环境决定由 Stella 执行部署,还是由 Stella 为您现有工具执行的部署把关。
产品控制台显示的命令(v1.0-RC1)。
我可以将 Stella 与 Vanta、Drata 或其他合规工具一起使用吗?
可以。合规计划所引用、却无法自行产出的制品级证明,正是 Stella 提供的:对任一发布,部署了什么、摘要是什么、通过了哪条策略、由谁批准、在哪一天。这条记录读自部署本身,并可从同一份证据确定性地重跑——明年得到的答案就是今天的答案。
这条记录以八种面向监管机构的签名档案导出:NIS2 适用性声明与有效性报告;DORA 信息登记册、重大 ICT 事件报告、第 45 条信息共享与 TLPT 证据包;CRA 技术文件与符合性档案。每一份都经过密封与签名,可对照已公布的信任根离线验证——核验签名完全不需要访问您的 Stella 实例。
您已经在跑的合规计划无需做任何改动。每份导出都是一个可携带的签名文件:把它附到它所证明的控制项上、交给审计方,或通过保障导出接口取回。而在导出之前,就绪检查会逐个档案指出还缺什么——缺口在您还来得及补的时候浮现,而不是在审计当场。
还有问题?
查看文档获取技术细节,或加入社区获得支持。
