從文物摘要到活生生的證明

每次發行都沿著一條脊椎前進。每個階段都保存與文物摘要相關聯的證據,且每個階段都處於一個狀態:MISSING、記錄或簽名。部署後,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 通往你的建置系統的網路路徑。

簽名是在建置時發生的,因此證據不依賴於哪個CI產生了它。

The gate call →

四個輸入類別供養脊椎。證據會在產生地點簽署,然後由控制平面驗證。

登記冊 · 透過 CLI 取得管線證據 · 諮詢與VEX來源 · 秘密 — Every source named, and what each one feeds →

羈押脊

七個階段,一個產出物摘要。這是當有人問你在執行什麼以及為什麼被允許時會打開的頁面。

觀看執行 · 4 分鐘

一次在閘門被拒的發布與一次獲准的發布、隨後完成的部署、每個決策背後已封存的決策膠囊、exposure 工作集收斂到真正會攔截的部分、custody 鏈路,以及資產矩陣。
保管鏈畫面:從 Source 到 Watch 的七階段時間軸,每個階段均標記為 MISSING
Stella Ops 主控台中的保管鏈,本機開發環境。該主體的每個階段都顯示 Missing——沒有原始碼血緣,沒有建置溯源。系統不會推斷內容來填補這些缺口,也不會把空白視為正常。

每個階段恰好處於三種狀態之一:

MISSING

此階段沒有證據。在證據送達之前,它會持續回報 MISSING。

RECORDED

證據存在並綁定於文物摘要中,但尚未簽署。

SIGNED

證據帶有DSSEDead Simple Signing Envelope - 用於以加密簽章簽署任意資料的簡單靈活標準簽名,且可離線驗證。

  1. 1

    資料來源

    產出物聲稱來自的提交和儲存庫,是從你的管線錄製的——從未被推斷。

  2. 2
  3. 3

    掃描

    SBOM軟體物料清單 - 軟體中所有套件和相依性的完整列表與脆弱性分析綁定於該摘要。新的摘要代表新的掃描;結果絕不會帶到原本未被製作的版本中。

  4. 4
  5. 5

    判決

    閘門結果及任何人工核准,都記錄在產生該結果的政策版本中。

  6. 6

    部署

    核准摘要在指定環境中推進:什麼內容、在哪裡執行、何時執行。

  7. 7

    持續比較執行中的摘要與核准摘要。漂移是被偵測到的,而不是被假設消失。

閘門評估:可達成的風險,而非原始計數

閘門根據版本化政策評估已簽署的發現。Reachability分析證明易受攻擊的程式碼是否確實被您的應用程式呼叫——過濾掃描器雜訊中的誤報 分析會將造成阻擋的範圍收緊到位於你的程式碼可執行路徑上的發現。它涵蓋 Go、Java、C#/.NET、JavaScript 與 TypeScript、Python、Rust、PHP 與 Ruby;這些語言以外的發現則保留在工作集中——它們不會預設被標記為不可達。

在示範曝光畫面:7發現→ 1阻擋(可達×未修復)。那個會阻止發行。其他六個都保持可見,一個過濾掉了。

背景說明:~85% 的關鍵容器漏洞存在於非活躍程式碼中(Sysdig 2024 容器安全報告)。

終端
$ stella gate evaluate --env staging --image sha256:8c1a4f…

產品主控台(v1.0-RC1)所示指令。

無法執行的支票會被報告為未評估並記錄在判決中。這從未被算作通過。

Stella Ops 主控台的晉級畫面:從「等待核准」到「已退役」的六種生命週期狀態,並顯示每次晉級的狀態與風險訊號
Stella Ops 主控台中的晉級,以範例資產呈現。每次晉級都恰好處於一種生命週期狀態,其閘門狀態也隨之一併流轉。
阻擋發行的是什麼——先是可達、尚未修復、與政策相關的風險。長尾只需一個篩選條件。

每一次失敗的支票都會標明觸發的規則、所讀到的證據,以及背後的發現。答案就在結論中——不是重新執行掃描器或與資安團隊的訊息串。 「為什麼我的發行被阻擋了?」 →

若 Stella Ops 無法存取,閘門將阻斷。

掃描器或政策引擎逾時依設計視為失敗,而非放行;CLI 中不存在任何 fail-open 開關。無法取得掃描結果的產物不會被部署。

在故障期間發布是一次有意且可追責的行為,而不是變通:一個已簽署、限定範圍且有期限的例外,記錄在做出該決定的維運人員名下,並在首次使用前完成組態。

break-glass 的完整機制 →

證明依據

每個聲明都連結到可檢查的證據產出物、重播工作流程及規格文件。

證明與方法論連結: 證據與稽核 | Decision Capsule 規格 | 營運與部署

部署:將核准摘要部署至非 Kubernetes 目標

部署階段會推出核准的摘要,並記錄哪些內容放了哪裡。目標是大多數發行工具忽略的資產。

  • → Docker Compose 專案
  • → SSH/WinRM 主機 — 設計上無代理
  • → HashiCorp 遊牧者
  • → 滾動、金絲雀與藍綠策略
  • → 回滾會重新指向一份已知且已存檔的摘要
  • → 每個部署檔案摘要、環境與時間

回滾是對一個已獲核准摘要的可驗證部署,而不是流程之外的例外。

營運與部署 · 部署到伺服器而不安裝代理

看著:證據必須持續存在

核准是一個時間點。部署後,Watch 會將每個執行中的摘要與該服務及環境核准的摘要進行比較。部署始終無代理——不在您的主機上安裝任何東西。監控由 Stella Ops 代理服務完成:它從可存取的 Docker 常駐程式讀取實際執行的映像檔摘要。代理服務執行於你自己的 Stella 安裝內,而不是在你的主機上,並透過 Docker API 讀取。

漂移,乘積中定義為:

“執行摘要並非已核准/部署的摘要(未經核准或修改映像檔)”

無法觀察Stella環境被證明為未經證實,從未被假設為健康環境。

Watch 觀測的單位是容器,以映像摘要標識——因此漂移偵測涵蓋你主機上的容器化負載,無論其執行在經 SSH 的 Docker、Compose 還是 Windows 常駐程式上。

邊界說清楚:在容器之外執行的東西,就在 Watch 的證明之外。部署到裸主機的檔案、服務或可執行程式帶有部署證據——誰在何時從哪個以摘要標識的發布部署了什麼——但不會按映像摘要被持續複核。

見整個環境資產的漂流 →

深入了解

Stella 與 架構概覽 稽核人員獲得什麼

準備好看到它的實際應用了嗎?

查看所有功能 | 證據與稽核 | 文件