从制品摘要到活生生的证据
每次发布都沿着一条证据保全链主干移动。每个阶段都保存与制品摘要相关证据，且每个阶段处于一个状态：缺失、记录或签名。部署后，Watch不断检查证据是否依然成立。
初始设置后，您将拥有：
- 1. 将漏洞积压筛选为真实工件的可达风险发现
- 2. 每次晋级决策都导出签名
Decision Capsule签名的可导出证据包，封装发布决策的每个输入和输出，用于离线审计和确定性重放 - 3. 从开发到阶段的完整升级，有证据
Stella Ops 的定位
Stella 位于您的 CI 和服务器之间。CI 构建镜像。Stella 决定是否可以晋级，将其部署到非 Kubernetes 目标（Compose、SSH/WinRM），并导出审计证明。
从任何 CI/CD 系统进行门禁校验
无论用什么执行部署——Jenkins、Octopus 步骤、GitLab CI、GitHub Actions，还是构建机上的一段 shell 脚本——接入 Stella 的方式都一样：加一个运行 CLI 的阶段。
当闸门拦截时，命令以非零状态退出，于是该阶段失败、流水线停止。除此之外不需要接任何东西：没有入站 webhook，没有回调 URL，也没有从 Stella 通往你的构建系统的网络路径。
签名发生在构建阶段，因此证据不依赖于是哪个配置组产生的。
四个输入类别为证据保全链主干提供能量。证据在产生地点签字，然后由控制平面进行核实。
登记册 · 通过CLI获取管道证据 · 咨询与VEX来源 · 秘密 — Every source named, and what each one feeds →
证据保全链主干
七个阶段，一个制品摘要。这是当有人问什么在运行以及为什么允许时你打开的页面。 观看运行 · 4 分钟
每个阶段恰好处于三种状态之一：
MISSING
该阶段没有证据。在证据到达之前，它一直报告 MISSING。
RECORDED
证据存在并被绑定在制品摘要中，但尚未签署。
SIGNED
证据带有DSSEDead Simple Signing Envelope - 用于以加密签名签署任意数据的简单灵活标准签名，且可在离线验证。
- 1
资料来源
工件声称来自的提交和仓库，是从你的流水线录制的——永远不会被推断。
- 2
- 3
扫描
SBOM软件物料清单 - 软件中所有软件包和依赖项的完整列表和漏洞分析都绑定在该摘要上。新的摘要意味着新的扫描;结果从未被带入未被制造的构建中。 - 4
- 5
判定
工单结果和任何人工批准，都记录在产生它的政策版本中。
- 6
部署
批准摘要向指定环境晋级：哪些内容运行、在哪里运行、何时运行。
- 7
观看
持续比较运行中的摘要与批准摘要。漂移是被检测到的，而不是被假定消除。
工单评估：可达风险，而非原始计数
门禁根据版本化策略评估已签名的发现。Reachability分析证明易受攻击的代码是否确实被您的应用程序调用——过滤扫描器噪声中的误报 分析将造成阻断的范围收紧到位于你的代码可执行路径上的发现。它涵盖 Go、Java、C#/.NET、JavaScript 与 TypeScript、Python、Rust、PHP 和 Ruby；这些语言以外的发现仍留在工作集中——默认不会标记为不可达。
在演示的曝光界面：7发现→ 1阻挡（可访问×未修复）。那根会阻止发布。另外六个保持可见，一个滤镜被关闭。
背景：~85%个关键容器漏洞存在于非活跃代码中（Sysdig 2024 Container Security Report）。
$ stella gate evaluate --env staging --image sha256:8c1a4f…
产品控制台显示的命令（v1.0-RC1）。
无法执行的支票会被报告为未评估并记录在判定中。这从来不算作通关。
阻碍运输的因素——首先是可达、未固定、与政策相关的风险。长尾只需一个滤芯。
每一次失败的支票都会标明发射的规则、所读到的证据以及背后的发现。答案在于判定——而不是重新运行扫描仪或与安全团队的消息线程。 “为什么我的发布被阻挠了？” →
若 Stella Ops 无法访问，闸门将阻断。
扫描器或策略引擎超时按设计视为失败，而非放行；CLI 中不存在任何 fail-open 开关。无法取得扫描结果的工件不会被部署。
在故障期间发布是一次有意且可追责的行为，而不是变通：一个已签名、限定范围且有期限的例外，记录在做出该决定的运维人员名下，并在首次使用前完成配置。
部署：向非Kubernetes目标提交批准摘要
部署阶段会发布批准的摘要，并记录哪些内容放哪里。目标是大多数发布工具忽视的资产。
- → Docker Compose 项目
- → SSH/WinRM 主机——设计上无代理
- → HashiCorp 游牧者
- → 滚动策略、金丝雀策略和蓝绿策略
- → 回滚则指向一份已知且有效的摘要，其证据已存档
- → 每个部署记录摘要、环境和时间
回滚是对一个已获批准摘要的可验证部署，而不是流程之外的例外。
看：证据必须持续存在
批准是一个时间点。部署后，Watch 将每个运行中的摘要与该服务和环境的批准摘要进行比较。部署始终无代理——不在你的主机上安装任何东西。监控由 Stella Ops 代理服务完成：它从可访问的 Docker 守护进程读取实际运行的镜像摘要。代理服务运行在你自己的 Stella 安装内，而不是在你的主机上，并通过 Docker API 读取。
漂移，正如乘积所定义的：
“运行摘要不是批准/部署的摘要（未经批准或修改过的映像）”
Stella无法观察的环境被描绘为未经验证，从未被假定为健康环境。
Watch 观测的单位是容器，以镜像摘要标识——因此漂移检测覆盖你主机上的容器化负载，无论其运行在经 SSH 的 Docker、Compose 还是 Windows 守护进程上。
边界说清楚：在容器之外运行的东西，就在 Watch 的证明之外。部署到裸主机的文件、服务或可执行程序带有部署证据——谁在何时从哪个以摘要标识的发布部署了什么——但不会按镜像摘要被持续复核。
深入了解