集成
連結那些讓發行決策成為可能的來源
建置與掃描證據根本不需要連接器——CLI 會在建置工作中簽名。
發行決策由四類來源提供：登錄資料、管線證據、諮詢與VEX資料，以及機密資料。這些問題都落在同一條羈押線上——資料來源：→ Build → Scan → Verdict → Decision → Deploy → Watch。
連接埠不是護城河
管線證據（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 / Artifact登錄庫 · 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避難所 · Azure Key Vault · AWS Secrets Manager · HSM / PKCS#11. 內建秘密儲存庫: 登錄與部署憑證存放於秘密儲存庫，並在執行時注入。 秘密價值不會出現在證據或Decision Capsule中。
諮詢與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 可與您已有的內容配合使用。從單個登錄庫開始，然後從那裡擴展。