观看——证据保全链主干第七阶段
批准和跑步是不一样的
资产环境矩阵涵盖了每个服务与每个环境：部署了哪些摘要，以及支持其的证据。部署后，Watch会持续将运行中的摘要与批准的摘要进行比较——当它们不同时，矩阵也会发生变化。
不是计划中的重扫。观察跑步的时间取决于工作量。
证据保全链主干
- 资料来源
- 建造
- 扫描
- 结论
- 判定
- 部署
- 观看
每个关卡有三种状态之一：MISSING、RECORDED或SIGNED。前六个阶段已完成。但Watch没有——它不断检查记录是否与现实相符。
一个矩阵，所有环境
下方的资产视图：服务在左侧，环境在顶部，展开的偏差面板在其下方。未证实的单元格已记录部署，但证据尚未验证。一条偏差是某个代理对某个运行中容器的报告，该容器的摘要不在批准之列；被篡改的发现另有单独计数。 Digest-first基于不可变内容哈希（SHA-256摘要）而非可变标签的发布标识——确保逐字节一致的部署
屏幕使用的四个术语
资产环境界面上的所有内容都归结为部署内容、已证明内容以及批准后发生了哪些变化。
未经验证的细胞
部署被记录，但背后的证据不完整。单元格不会因为善意而变绿。
漂移
观察者会将每个工作负载实际运行的摘要与该环境批准的摘要进行比较。不匹配变成了漂移论：哪个服务、哪个环境、哪个摘要不一致。
被篡改
完整性违规：运行中的镜像相对于其签名记录被修改。被篡改的发现与漂移分开计入，因为篡改镜像与未经批准的镜像是不同的问题。
为什么这在Kubernetes之外很难做到
Kubernetes 集群有一个准入层：工作负载可以在调度时被拒绝。Compose 项目、SSH/WinRM 主机 任务和 作业没有相应的门。扫描仪会停在发现处。CD工具在部署事件时停止使用。准入控制只在 Kubernetes 内部验证，且无论如何都不会留下可重放的决策证据。所以在大多数非Kubernetes资产环境中，没有任何程序能检查当前运行的内容是否仍是批准的。Watch弥补了这一空白：对没有准入层的资产环境进行持续摘要比较，并记录每一次检查。
操作原理
无代理部署目标
Stella Ops 通过每个目标的独立接口，晋级到 Docker Compose、SSH/WinRM 主机 的版本。部署时目标上什么也不会安装。
观察性代理
观看是分开的。轻量级观察者报告每个靶点上实际运行的摘要。当没有观察者运行时，运行状态缺失——从未被假定为良好。
漂移划船能让你做什么
- 追踪护照：哪本摘要被批准用于该环境，基于何证据，由谁批准。
- 重新核实：根据现有证据再次核查并记录结果。
- 回滚：重新部署最后已知有效的摘要——一个精确的制品，而不是标签。
谁会阅读此屏幕
发布行动管理员
什么是Live？哪里？
一个矩阵回答了这个问题：每个服务、每个环境、部署摘要、证据态势。不要交叉比对部署日志和注册表。
保证查看器
是否部署了合适的软件——并且符合州政府规定？
每个单元的只读状态：运行内容、证据链是否完整以及上次检查时间。
安全风险管理师
有没有什么我们不认可的运行内容？
未经批准或修改的镜像会以漂移和篡改的行形式出现，并与批准的摘要进行比较。是定期检查，不是定期报告。