常见问题

不需要，而且这正是设计初衷，而非局限。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 是证据保全链主干的最后一个阶段（Source → Build → Scan → Verdict → Decision → Deploy → Watch）：它将每个环境中实际运行的摘要与该环境获批的摘要进行比较。

两者不一致时，该服务会被标记：运行中的摘要不是已批准/已部署的摘要（未经批准或被篡改的镜像）。你能准确看到是哪个服务、在哪个环境中偏离了其批准状态。

Watch 没有证据的服务会报告 Missing——绝不会因为假定没有变化就显示为一致。

查看 Estate 视图 →

可以，而且这由产品本身强制执行，而不是交给你的网络去保证。封闭模式（EgressPolicyMode.Sealed）会阻断出站流量；stella offline import --bundle 导入已签名的离线包；stella evidence verify-offline 在完全不联网的情况下检查校验和、清单、DSSE 绑定以及 Rekor tile 覆盖情况，一旦发现任何篡改即判定失败。

Offline Kit 打包了漏洞数据源、容器镜像和来源证明（provenance）数据。无论在线还是在主权网络中，扫描结果都完全相同。

查看 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 天之间的有效期（无期限的例外会被拒绝）、承担责任的操作者签名，以及最近五分钟内的重新认证。它会记录在该发布上。请注意它需要先行配置：在未修改的安装中签名通路并未接通，因此在你登记操作者密钥之前，请求会被拒绝。

门禁并不需要整个平台。一次部署决策依赖约十个服务——数据库、发布编排器、扫描器、策略引擎、身份与网关——而不是整套产品；证据封存、通知与时间线审计都不在决策通路上。

部署到裸虚拟机是一等能力：通过 SSH、WinRM 或 Ansible，Stella Ops 可以放置文件、重启服务，或在主机上运行操作者提供的可执行文件，并把命令、其输出与退出码作为证据捕获——无需容器。

持续 Watch 则更窄，值得说清楚。Watch 与可达性按镜像摘要观测运行中的容器——漂移检测正是据此得知运行的制品仍与已批准的相符。若无法从某主机读取容器，则显示为未观测，绝不假定其健康。因此，无 Docker 主机上的裸进程会被部署且其运行被记录，但不会像容器化工作负载那样被持续监测漂移。“普通服务器”指在 Kubernetes 之外运行容器的服务器——而非任意的非容器化进程。

不必。授权操作者自行放行。你提出一个限时的策略例外，走你配置的审批流程：具名审批角色、最少审批人数、原因代码、佐证材料及任何补偿性控制，并设最长有效期。自审批是你设定的开关，而非我们强加的默认值。

获批的例外会翻转那一条具体发现——抑制、延后、降级或要求某项控制——并连同谁在何时批准写入该决策的审计轨迹。它可用 DSSE 签名，因此放行是可问责、可重放的，而不是从记录中消失的静默绕过。

有一条底线被刻意设为不可豁免：每个部署制品都必须带有真实的扫描通过。例外解决某条具体策略发现；它绝不解除“该制品必须先被扫描”这一要求。

开箱即用时，Stella Ops 维护自己的本地用户，并使用 Argon2id 对密码进行哈希。SAML、OIDC 与 LDAP/Active Directory 连接器随平台签名交付；启用其中之一是运营方的配置步骤，而非默认设置。安装 bundle 为每个连接器都附带一个配置文件。

访问按租户隔离并以权限为基础，而不是粗放的角色划分。平台提供 200 多个具名权限，因此要紧的动作都是各自独立的授权：批准策略例外、绕过发布门禁、轮换密钥加密密钥，各自都是一项权限。你可以让某人能读取发现，却无权解除拦截。

变更操作记录在产品自己的审计轨迹中，并有其单独的读取权限——它独立于发布所携带的签名证据链，是其之外的补充。这些都不受方案限制：免费版和授权版包含全部能力。

这问得对，我们不会回避：签名证明的是你的安装产出了该判定，因此被攻陷的控制平面可以签出一份看似有效的记录。设计所做的，是让这份记录难以被盲目信任、且易被识破。

验证依据你自己配置的信任根进行，缺失时直接失败——它绝不调用任何 Stella Ops 服务来决定该信任什么。每个判定都对你指定的时间戳机构加盖时间戳，并可对你自己运营的透明日志做包含性登记——于是“何时”和“是否曾被记录”都锚定在受审计的系统之外。

最强的检查是重放：每个判定都从其密封输入重新计算，重算不出相同答案的记录即失败。在可疑控制平面无法掌控的基础设施上重跑重放，伪造的判定便无法通过重算。这一切都不会让被攻陷的平面变得无害——它把信任锚移出该平面，并给你一条独立途径来识破谎言。

没有任何内容被删除。可达性改变的是一条发现是否阻断晋级，而不是它是否存在：该发现连同被赋予的状态一并留在记录中，闸门证据会把发现的总数与真正造成阻断的子集并列记录。不存在需要事后还原的抑制步骤。

证据胶囊会说明原因和时间。它按摘要绑定产生该判定的每一项输入：SBOM、公告快照、状态所依据的可达性证据，以及作用于其上的策略标识和版本。促成该发布晋级的审批记录在发布本身上，位于证据保全链的 Decision 阶段。

而且它会重新计算。重放会在离线环境中依据这些封存输入重新执行判定，并与记录的结果比对，若不一致则报告差异；无法真正重新计算的重放会失败，而不是把已存判定回抛给你。发生事故之后，决策当时已知的内容是有记录可查的事实，而不是争论的对象。

残余风险归你。是你的策略决定了哪些状态阻断、哪些不阻断，而闸门的价值不会高于其背后的策略。Stella Ops 主张的是该决策有证据支撑且可重放，从未主张该决策是正确的。在编写该策略之前值得知道：只有已证实的可达路径才能阻断发布，因为“未观察到路径”并不能证明路径不存在，也不会被这样记录。

证据与审计 → 可达性的工作原理 →

判定会重新打开。安全公告的时效性不是一份事后才看的报告——新的公告数据会重新评估已经做出的决策，受影响的发布会被标记。

周二正确的决策，到周四就可能不再正确，而你的资产环境中什么都没变。只在晋级时评估的系统看不到这一点。

每个数据源的数据时效都会在界面上逐一显示。数据是否过时始终可见，绝不隐藏。

一个在隔离环境中悄悄使用一个月前的公告数据、看起来却一切正常的安装，比一个拒绝启动的安装更糟。Stella Ops 会向你显示其决策所依据数据的时效，而导入 Offline Kit 时会记录快照摘要，因此数月后的重放使用的正是你当初决策时的数据。

一份他们可以自行核验的材料，无需信任我们，也无需安装任何东西。已发布的示例胶囊可用 cosign verify-blob 和 sha256sum 在约三十秒内完成验证。

• 扫描了什么（确切的工件摘要）
• 发现了什么（SBOM?软件物料清单 - 软件中所有软件包和依赖项的完整列表 + 可达性）
• 为什么批准（策略判定）
• 谁批准的（签名的审批）

审计员可以独立验证签名，并使用 stella replay 离线重放决策。

产品控制台显示的命令（v1.0-RC1）。

不需要。证据来自你现有构建作业中运行的 CLI。stella ci init 会生成流水线步骤的脚手架；CLI 在作业内对构建证据签名（stella attest sign）。

不需要任何连接器——任何能运行二进制文件的 CI 都可以。Stella 使用的是签名摘要和证据，而不需要访问代码仓库。

产品控制台显示的命令（v1.0-RC1）。

合规包将证据保全链中的证据映射到 NIS2、DORA 和 CRA 义务。启用后会以保守的纯证据模式开始收集证据；它并不声称已满足监管合规要求。

运营方始终是受监管的决策者。Stella 帮助你汇编并签署监管机构所期望的材料——它从不代为提交，也从不认证。

部分写入路径仍在完善中——例如，ENISA 自动提交传输仍在等待官方 schema（目前由运营方将文件投放到文件系统）。每个合规包的当前状态都在合规页面上说明。

合规包详细介绍 →

你的安装中一个环境里的一个受管工作负载：可以是容器服务，也可以是通过 SSH 或 WinRM 部署到主机、以摘要寻址的工件；两者计数相同。当 Stella Ops 部署、把关或晋级某个工作负载的发布，扫描其已安装的镜像或工件，或将先前的扫描结果应用于该已安装的工作负载时，这一“工作负载–环境”关系即可计入。应用先前的结果不需要运行新的扫描。每个符合条件的关系只计一次，即使同时涉及其中多项活动。

部署位按安装计数——一个安装即 Stella Ops 控制平面的一次逻辑部署：同一部署中的集群节点、数据库副本和故障转移组件合并计算，独立运营的安装各自单独计算。Stella Ops 自身的基础设施从不计入。当该环境中对该工作负载的所有管理实际结束时，或工作负载已被移除且没有其他管理活动使其保持有效时，部署位即告结束；扫描完成不会结束部署位，仅保留历史证据或报告也不会产生、重新激活或维持部署位。

当前发布版本不显示部署位总数。如果 Stella Ops 部署、把关或晋级某个工作负载的发布，扫描其已安装的镜像或工件，或将先前的扫描结果应用于它，请将该工作负载在每个环境中计一次。Estate 视图列出了 Stella Ops 执行过的部署；你还必须计入所有其他符合条件的工作负载，包括由其他工具部署的工作负载，以及自动清单中未显示的工作负载。

什么算作受管部署位 →

不会。一个环境中某个工作负载的五个副本是一个部署位。重启它、重新部署它，或在同一环境中为同一工作负载推出新的镜像版本或摘要，都不会增加部署位。

三个。一个部署位是一个环境中的一个工作负载，因此在开发、预发布和生产环境中运行的一个工作负载是 3 个部署位，十个工作负载分布在三个环境中就是 30 个。环境本身从不受限制，也从不计价。

不会。扫描、重新扫描、漏洞报告、晋级和部署均不按次收费。扫描已安装工作负载的镜像或工件，或将先前的扫描结果应用于它，可能使该工作负载在每个相关环境中计入部署位数量。每个“工作负载–环境”关系只计一次，与扫描或报告的次数无关。

仅将报告作为历史证据保留或查看，不会产生部署位。将先前的结果作为适用于某个已安装工作负载的扫描信息呈现，即视为应用该结果。扫描未安装在你任何环境中的镜像或工件，不会产生部署位。

每个安装中超过 20 个部署位的生产使用需要授权版：一份部署位容量不少于你所管理的部署位数量的许可。容量最多 100 个部署位时每月 $100，超出部分按容量计，每个部署位每月 $1；超过 20 个后，所有部署位都计入——免费的 20 个不予扣除——因此 30 个部署位的容量每月 $100，200 个则为 $200。

增加容量自下单时生效，并自该日起按比例计费；减少容量在续订时生效。

如果你发现自己无意中超出了已订阅的容量或免费的 20 个部署位，可以自发现之日起继续使用 14 天，在此期间减少用量或订购容量。这一宽限只适用于无意超出，不适用于故意或反复超出。

现在即可订阅：发送邮件至 sales@stella-ops.org，订单将通过授权登记商户下达。在线结账即将推出。

费用是多少？ →

授权版有 $100 的每月最低收费，该最低收费涵盖最多 100 个部署位：21 个部署位和 100 个部署位每月都是 $100。从 101 个部署位起，价格为每个部署位每月 $1——101 个每月 $101，150 个每月 $150。

不会有任何功能被关闭。当前发布版本不强制执行部署位上限，也不检查许可证，因此你的软件、工作负载、扫描和部署都会继续运行，每条证据记录也仍可用你自己的信任根验证。

不过，付费容量仅在订阅期限内获得许可。期限结束后，超过 20 个部署位的生产使用需要续订，或缩减到 20 个部署位或以下。

不需要。没有许可证服务器、没有激活，也不回连：当前发布版本不检查许可证，因此隔离环境中的安装与联网安装的许可方式完全相同。你的免费使用由许可证条款决定，付费容量由你的订单决定——而不是由与我们的连接决定。

漏洞情报更新通过 Offline Kit 送达离线安装，每个数据源的数据时效都会在界面上逐一显示。

由你的订单记录。授权版通过授权登记商户购买，订阅的部署位容量不得少于你所管理的部署位数量；被接受的订单依据 Stella Ops 客户协议写明该容量和订阅期限。

当前发布版本不导入也不检查该记录，因此让安装保持在其范围内是你的责任。订阅期限结束时，软件中不会有任何功能被关闭，但此后超过 20 个部署位的生产使用需要续订，或缩减到 20 个。

客户协议 →

你的安装生成的证据由你的安装自己的密钥签名，而不是我们的密钥。可移植证据包可针对你声明的信任根完全离线验证：stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>。它检查校验和、清单绑定和签名，任何一项不通过即判定失败。

Stella Ops 的发布版本另行签名：发布 bundle 和镜像都使用 Cosign 签名，公钥发布在验证密钥页面上。发布签名表明一个 bundle 来自我们；证据签名表明一条记录来自你的安装。

验证密钥 →

可以，通过与人员相同的接口。你运行的 CI 作业、脚本或 AI 代理以 OAuth 客户端凭据服务客户端的身份进行认证，并通过发布 API 或 stella release approve|reject|promote|deploy|rollback 驱动发布。审批与策略门禁由服务器评估，因此自动化调用方与人员受同一策略约束。

其他扫描器同样可以接入：stella sbom upload 导入外部 CycloneDX?业界广泛使用的软件物料清单（SBOM）开放标准格式 或 SPDX?软件包数据交换 - 另一种广泛用于开源的SBOM开放标准格式 SBOM，并记录生成它的工具；stella gate score batch --sarif 让其他工具的 SARIF 发现经过同一个发布门禁。

一次评审针对一个明确界定的问题。工程师分析你提供的信息，并以书面工程答复回复：可能的原因，以及我们建议的纠正或诊断步骤。

它不包括无限工程工时、定制开发、保证修复或持续咨询，也没有持续性的服务级别。购买前，我们会告知预计的交付时间范围；在获得所需信息后，我们会在合理时间内以书面形式答复。在索取日志之前，我们会告诉你如何安全地发送诊断数据。如需购买，请发送邮件至 support@stella-ops.org，并附上问题的简短描述。

如果评审表明主要问题是受支持且配置正确的发布版本中可复现的缺陷，费用将予以退还；如你愿意，也可改为抵扣额度。

文档、Doctor 诊断和自助故障排查对所有人免费；报告产品缺陷或安全漏洞从不需要付费评审。

Stella Ops 处于候选发布阶段（v1.0-RC1）。

• 现在：v1.0.0-RC1-20261029——已签名 bundle 与镜像均为公开，可从 get.stella-ops.org 与 registry.stella-ops.org 匿名获取
• v1.0 发布之前：至少两家客户在生产中运行，且公共 API 接口冻结
• v1.0 预计于 2027 年元月 1 日发布
• 代码以 BUSL-1.1 源码可用方式提供
• 无论如何都不变：向下兼容的证据格式与确定性重放

如何开始使用 →

目录登录默认不启用。LDAP、OIDC 和 SAML 插件随 v1.0.0-RC1-20261029 签名交付，安装 bundle 为每个插件都附带一个配置文件，但 Stella Ops 不提供零配置的目录登录：你需要将插件指向你的目录并启用它。

它也不是 Kubernetes 工具——这是有意的定位，而不是缺口。它不扫描恶意软件，也不提供美国联邦合规包。如果其中任何一项是你的决定性需求，目前其他工具会更合适。

Stella 将发布建模为晋级图（Dev → Stage → Prod）。在每个关卡：

• 根据工件的证据评估策略
• 审批使用加密签名记录
• 为审计生成Decision Capsule?签名的可导出证据包，封装发布决策的每个输入和输出，用于离线审计和确定性重放

晋级与工件摘要绑定，而非标签。相同摘要 = 复用相同证据。

Stella Ops 在欧洲开发，由一家在保加利亚注册的公司运营；我们自己的基础设施——本网站、镜像仓库和更新通道——托管在瑞士，瑞士已获得欧盟数据保护充分性认定。你的供应链中没有总部位于美国的供应商。完整的运营方信息见法律声明。

该平台为自托管，因此你的工件、SBOM 和证据都保存在你自己的基础设施上——如有需要，可在完全隔离的网络中运行。欧洲管辖权加上自托管，意味着唯一持有你发布证据的就是你自己。

对于处在发布路径上的任何组件，这都是合理的问题。设计层面的回答是：日常运行从不依赖于能否联系到我们。产品自托管，可在隔离环境中运行；没有许可证服务器，也不依赖我们的云服务，而且当前发布版本中没有任何部分检查许可证，因此订阅结束时不会有任何功能被关闭——但此后超过 20 个部署位的生产使用需要续订，或缩减到 20 个。

你的证据同样不需要我们。判定与胶囊可离线验证——stella replay 从封存的输入重新计算决策，全程不涉及任何 Stella Ops 服务或账户。

代码依据 BUSL-1.1 源码可用：你可以阅读、构建并修补所运行的版本。许可证还内置了到期机制——每个版本在其变更日期（Change Date）转为开放许可证，当前版本最迟为 2030 年元月 20 日。日常运维你也不依赖我们：stella doctor 运行安装的诊断检查，stella doctor export 打包用于支持的诊断包，stella doctor fix 应用非破坏性修复。源码位于 git.stella-ops.org。

日常运行中，产品能够自我支撑。Doctor 对整个栈做健康检查，并针对发现的问题给出修复步骤；在维护窗口内，它自行执行非破坏性修复，破坏性修复则只在审批门禁之后执行，并附带试运行预览和持久的审计记录——否则就把手动步骤交给你。在此之上还可以获得人工帮助：以付费方式评审一个明确界定的问题，而不是靠它来维持你的安装运行。如果你的采购需要合同化的连续性条款，请在评估期间与 sales@stella-ops.org 商定范围。

验证密钥、已签名的证据示例以及架构和加固文档均已公开，汇总在供应商安全审查页面上，该页面同时说明了我们的认证情况。客户参考案例即将推出——来自我们内部测试版的结果。尽职调查的讨论范围可在评估期间确定。

供应商安全审查 →

订购、付款、税务和开票由授权登记商户处理——参见结账说明。现在即可通过邮件下单：授权版请联系 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 个受管部署位范围内免费用于生产。超出该范围，生产使用需要授权版，即按部署位数量授予的许可。变更日期——每个版本发布后四年——之后，代码转为 Apache-2.0。

这种模式为产品的持续开发提供资金，同时保持证据链完全可审计。

租户是一个隔离的工作空间，拥有自己的用户、角色、策略和证据历史。暂停一个租户会冻结其全部访问。

多个租户共享一个安装；证据和访问按租户隔离。这两个词回答的是不同的问题：

• Environment?逻辑部署目标（例如 dev、staging、prod），跟踪自己的发布历史、晋级规则和策略门禁（环境）是部署目标——发布在哪里运行，以及由哪条策略为其晋级把关。
• 租户是访问与证据的边界——谁能查看和操作，以及证据记入谁的证据历史。

一个租户通常包含多个环境。租户和环境都不计价：定价统计的是整个安装中的受管部署位。

可以。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）。

与 Trivy 对比 · 与 Snyk 对比 · 完整对比 →

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）。

与 Octopus Deploy 对比 · 哪些需要接入，哪些不需要连接器 →

可以。合规计划所引用、却无法自行产出的制品级证明，正是 Stella 提供的：对任一发布，部署了什么、摘要是什么、通过了哪条策略、由谁批准、在哪一天。这条记录读自部署本身，并可从同一份证据确定性地重跑——明年得到的答案就是今天的答案。

这条记录以八种面向监管机构的签名档案导出：NIS2 适用性声明与有效性报告；DORA 信息登记册、重大 ICT 事件报告、第 45 条信息共享与 TLPT 证据包；CRA 技术文件与符合性档案。每一份都经过密封与签名，可对照已公布的信任根离线验证——核验签名完全不需要访问你的 Stella 实例。

你已经在跑的合规计划无需做任何改动。每份导出都是一个可携带的签名文件：把它附到它所证明的控制项上、交给审计方，或通过保障导出接口取回。而在导出之前，就绪检查会逐个档案指出还缺什么——缺口在你还来得及补的时候浮现，而不是在审计当场。

合规领域现状，附来源 · 合规包详解 →