集成
连接那些使发布决策成为可能的来源
构建和扫描证据根本不需要连接器——CLI会在你的构建作业中签名。
发布决策由四类来源提供：注册、管道证据、咨询和VEX数据，以及机密。所有这些都落在同一条证据保全链主干上——→来源：Build → Scan → 判定→决定→部署→守望。
连接处不是护城河
管道证据（CLI）: 这个类别并不是一个连接者——这是故意的。构建和扫描证据不需要SCM连接器、CI连接器，也不需要入站webhook：CLI运行在现有流水线内，将签名证据推送出去。
连接器设计上是最难防守的层——任何厂商都能匹配标志网格。他们提供的内容更难复制：证据在源头签名，由控制平面验证，之后可重放。比较的是链条，而不是清单。
从任何 CI/CD 系统进行门禁校验
无论用什么执行部署——Jenkins、Octopus 步骤、GitLab CI、GitHub Actions，还是构建机上的一段 shell 脚本——接入 Stella 的方式都一样：加一个运行 CLI 的阶段。
CLI 以固定版本的容器镜像发布，运行器上无需安装任何东西。registry.stella-ops.org/stella-cli:v1.0 可匿名拉取——不需要凭据，不需要 CI/CD 变量，只需对镜像仓库的出站访问。没有该出站权限的运行器改为将 STELLA_CLI_IMAGE 指向内部镜像源。
$ docker run --rm \
-e STELLA_OCI_REGISTRY_USERNAME="$CI_REGISTRY_USER" \
-e STELLA_OCI_REGISTRY_PASSWORD="$CI_JOB_TOKEN" \
-v "$CI_PROJECT_DIR:/src:ro" \
registry.stella-ops.org/stella-cli:v1.0 \
sbom attach --generate --reachability --reachability-source /src \
--image "$IMAGE_REF" --digest "$IMAGE_DIGEST" \
--commit "$CI_COMMIT_SHA" --repo-url "$CI_PROJECT_URL" \
--source-id "gitlab-cr/$CI_PROJECT_PATH"
产品控制台显示的命令（v1.0-RC1）。
源码树以只读方式挂载到 /src，供可达性提取器读取构建该镜像的代码；容器以非 root 用户运行。镜像仓库凭据只从环境变量读取——CLI 拒绝以参数形式接收，因此不会泄漏到构建日志或进程列表中。
先从建议模式开始。在本例所出自的流水线中，每个 Stella 步骤都以 || echo … (non-fatal) 结尾：无论证据是否成功写入，构建始终保持绿色，因此团队可以先采用该步骤，再逐步建立信任。强制拦截是之后另行决定的事，不是开始的前提。
证据附加完成后，后续阶段即可据此拦截：stella gate evaluate --env staging --image sha256:… 会询问该摘要是否可以进入某个环境。
当闸门拦截时，命令以非零状态退出，于是该阶段失败、流水线停止。除此之外不需要接任何东西：没有入站 webhook，没有回调 URL，也没有从 Stella 通往你的构建系统的网络路径。
证据只向外流动。CLI 在作业内部签署构建证明并推送出去；控制平面从不反向进入来收取。
stella ci init 目前可为 GitHub、GitLab 和 Gitea 生成现成的流水线文件。其他 CI 系统直接调用同一个 CLI——命令完全相同，不同的只是外面那层 YAML。
建议的设置顺序
- 1 注册处——镜像和摘要的来源
- 2 流水线证据（CLI）——在构建作业中签名，无需连接器
- 3 咨询与VEX来源——是什么让判定保持最新
- 4 秘密——其他集成用什么认证
产品集成中心建议的顺序。
发布决策所依据的四个来源
登记册
Stella发现、扫描、变换并晋级的集装箱来源。摘要是所有其他事物所绑定的身份。 监视新摘要并拉取镜像以进行扫描和升级。 Digest-first基于不可变内容哈希（SHA-256摘要）而非可变标签的发布标识——确保逐字节一致的部署
Docker Hub · Harbor · AWS ECR · Google GCR/工件注册表 · Azure ACR · 任何符合 OCI开放容器计划 — 容器镜像格式和注册中心的行业标准 的注册表 — 任何符合 OCI开放容器计划 — 容器镜像格式和注册中心的行业标准 发行版规范的内容都可以工作。
通过CLI获取管道证据
CLI 会扫描每次构建，并在作业内签署构建证明（DSSEDead Simple Signing Envelope - 用于以加密签名签署任意数据的简单灵活标准）。流水线主动推送证据；控制平面不会进入构建系统收集证据。
咨询与VEX来源
咨询信息流: NVD国家漏洞数据库 - 美国政府基于标准的漏洞数据存储库 + OSV开源漏洞 - 面向开源项目的分布式漏洞数据库 + GHSAGitHub安全公告 - GitHub上软件包的安全漏洞数据库 · CISA网络安全和基础设施安全局 - 美国联邦网络安全指导和漏洞目录机构 KEV已知被利用漏洞 - CISA的活跃利用漏洞目录 · 国家CERTs计算机应急响应团队 - 发布漏洞公告的区域网络安全组织 · 供应商提要的版本生命周期. See the full source breakdown →
VEX摄入: 摄取并生成 VEX漏洞可利用性交换 - 关于漏洞是否在您的上下文中实际可利用的机器可读声明 语句以进行多颁发者信任解析。 >OpenVEX关于漏洞可利用性的VEX声明开放标准格式 · CSAF 2.0 · 自定义发行者. 自定义发行者: 供应商发布的 VEX漏洞可利用性交换 - 关于漏洞是否在您的上下文中实际可利用的机器可读声明，具有可配置的信任权重。 SBOM 和 VEX →
CSAF 2.0: 用于结构化通告的通用安全通告框架。
秘密
凭证存储，下游集成读取它。注册表和部署连接器持有一个秘密引用——从不包含凭证本身。
内置秘密存储 · HashiCorp Vault · Azure Key Vault · AWS Secrets Manager · HSM / PKCS#11. 内置秘密存储: 注册表和部署凭证存储在秘密存储中，并在执行时注入。 秘密价值不会出现在证据或资料盒中。
咨询与VEX来源
38活跃的咨询来源会提供漏洞评估——该计数已在产品的信息流状态界面实时显示。新闻源的新鲜度推动重新评估：当消息源更新时，受影响的判定会被重新评估，而不是依赖陈旧的数据。
冲突的 VEX 语句通过一个有记录的七态格子来解决，而解决本身也被记录为证据。
部署目标
将门控版本部署到非 Kubernetes 基础设施。
Docker Compose · SSH (Linux/Unix) · WinRM (Windows) · AWS / Fargate · HashiCorp · 脚本化（.NET 10）
每个层级的部署目标都是无限的。层级计量器环境和新摘要扫描——永远不会有目标。
The non-Kubernetes operating model Agentless SSH and WinRM deployment 看整个资产环境的漂流
谁可以登录
The default setup uses local users held by Stella Ops. Passwords are hashed with Argon2id.
SAML、OIDC 与 LDAP/Active Directory 连接器随平台签名交付，安装包为每一个都带有配置文件。启用是运维方的配置步骤，而非默认值。
All access is tenant-scoped. A user acts inside one tenant, and roles are evaluated within that boundary. TenantAn isolated workspace with its own users, roles, policies, and evidence history. Tenants share an installation; evidence and access are separated per tenant, and suspending a tenant freezes all of its access
按结构划分范围: 你的访问权限有四个限制。广泛的运营商或承包人权利从来不是提供自家服务的前提条件。
- 你的服务 你会看到并更新分配给你的服务，而不是整个资产环境。
- 你的仓库 访问会跟随绑定到你服务的仓库。其他团队的仓库不在你的职责范围内。
- 你的镜像命名空间 候选摘要是从绑定到你服务的镜像命名空间接受的，而不是注册表中的任何地方。
- 你的环境 你只在你岗位允许的环境中行动——直接更新或晋级请求，由环境决定。
自助服务需要你的平台团队为每个环境启用。如果有偏差，你的路径是向审批者申请晋级。Stella显示你可以触摸的环境;它本身从未让这个场景更广。
深入了解
准备好连接您的工具链了吗？
Stella Ops与您已有的一起工作。从单个注册表开始，然后从那里扩展。