常見問題

不需要，而且這正是設計重點，而非限制。Docker Compose、Swarm、SSH/WinRM 主機與指令碼化目標都是一等支援對象，而不是為尚未採用 Kubernetes 的人準備的退而求其次方案。

支援的目標：Docker Compose 專案、SSH/WinRM 主機。SSH/WinRM 部署無需代理程式——由 Docker 映像檔執行實際工作。

反過來也成立：如果您執行的一切都在 Kubernetes 上，Stella Ops 就不是適合您的工具。它是為環境資產的另一半而打造——虛擬機器、Compose 專案、一般伺服器——而多數團隊兩者並用。

它會顯示為 Missing（缺失）。不算通過、不假定健康，也不會被悄悄略過。

證據保管鏈的每個階段都處於三種狀態之一——Missing、Recorded 或 Signed。找不到所需證據的閘門不會退而判定為通過；NOT EVALUATED 永遠不會被算作通過。大多數工具把「沒有證據」當成「沒有問題」。這裡恰恰相反，而這正是其餘證據具有價值的原因。

可以。範例膠囊是一個真實的已簽署封存檔，您可以用現成工具檢查——cosign verify-blob 加上 sha256sum，完全不需要 Stella Ops。

該下載檔是經過去識別化、以示範金鑰簽署的樣本，因此除了本身之外不承載任何信任。stella evidence card verify 與確定性重播需要一個安裝以及由產品匯出的膠囊——對該樣本執行不會成功。

可以，而且可離線進行。裁決會依據產生它的凍結輸入確定性地重播：相同的 SBOM、相同的安全公告快照、相同的政策版本。

這正是兩種工具的差別：一種只告訴您答案；另一種在數個月後、在一台沒有網路的機器上、當著一個不信任您的人，仍能被要求展示推導過程。

部署之後，Stella 仍持續監看。Watch 是證據保管鏈（custody spine）的最後一個階段（Source → Build → Scan → Verdict → Decision → Deploy → Watch）：它會比對每個環境中實際執行的摘要與為該環境核准的摘要。

當兩者不一致時，該服務會被標記：執行中的摘要並非已核准／已部署的摘要（未經核准或遭修改的映像檔）。您能清楚看到是哪個服務、在哪個環境中偏離了核准狀態。

Watch 沒有證據的服務會回報 Missing——絕不會因為假定沒有變動就顯示為一致。

查看 Estate 檢視 →

可以，而且這是由產品強制執行，而不是交給您的網路來保證。密封模式（EgressPolicyMode.Sealed）會封鎖對外連線；stella offline import --bundle 匯入已簽署的離線套件；stella evidence verify-offline 完全不需網路即可檢查總和檢查碼、資訊清單、DSSE 繫結與 Rekor tile 涵蓋範圍，並在發現任何竄改時失敗關閉。

Offline Kit 打包了漏洞資料來源、容器映像檔與來源證明資料。無論是在線上還是在主權網路中，您都會得到相同的掃描結果。

查看 Offline Kit →

呼叫圖透過掃描管線為九種語言建構：Go、Java 與 .NET 為編譯器等級，Python、JavaScript、TypeScript、Rust、PHP 與 Ruby 則依據原始碼文字。每條邊都帶有產生它的分析層級。

較窄的情況更值得注意：在 CLI 中從原始碼樹建構呼叫圖僅支援 Go 與 Rust。其他語言都是以管線預先擷取的圖形式提供。涵蓋語言以外的發現不會被默默捨棄——它們會以未知項目留在工作集中，予以評分而不是略過。

目標記錄從不保存機密本身，只保存指向它的參照。機密本身以 AES-256-GCM 封存於依租戶派生的金鑰之下，且加密綁定租戶、擁有者與憑證身分，因此某一列的密文無法被當作另一列重放。隨後整筆目標連線記錄會在自己的密碼域中再次封存，然後才寫入資料庫。

主金鑰由您提供，我們從不產生。它可以來自環境變數、經權限檢查的掛載檔案、HashiCorp Vault 或 OpenBao，或 HSM。若未設定持久化儲存，所有封存與解析都會失敗，而不會靜默退回記憶體。

隔離與輪替是強制的，而非建議：每次查詢都依租戶過濾，跨租戶讀取回傳空值，甚至不洩漏憑證是否存在。輪替在寬限視窗內保留舊機密可解析，之後即失敗關閉；撤銷會抹除已存密文，使日後金鑰洩漏也無法復原。

受閘門管控的發布會被攔下，而不是被放行。如果掃描器或政策引擎無法存取，閘門按設計將逾時視為失敗——程式碼註解就是這麼寫的，而且 CLI 中任何位置都沒有 fail-open 開關。部署時同理：無法取回掃描結果的成品不會被部署。

在故障期間發布是一次有意且可問責的行為，而不是繞過。閘門例外需要一項預設無人持有的權限、書面理由、明確的風險確認、介於 1 到 365 天之間的有效期（無期限的例外會被拒絕）、承擔責任的操作者簽名，以及最近五分鐘內的重新認證。它會記錄在該發布上。請注意它需要先行設定：在未修改的安裝中簽名通路並未接通，因此在你登記操作者金鑰之前，請求會被拒絕。

閘門並不需要整個平台。一次部署決策依賴約十個服務——資料庫、發布編排器、掃描器、政策引擎、身分與閘道——而不是整套產品；證據封存、通知與時間軸稽核都不在決策通路上。

部署到裸虛擬機是一等能力：透過 SSH、WinRM 或 Ansible，Stella Ops 可以放置檔案、重啟服務，或在主機上執行操作者提供的可執行檔，並把命令、其輸出與離開碼作為證據擷取——無需容器。

持續 Watch 則較窄，值得說清楚。Watch 與可達性按映像摘要觀測執行中的容器——漂移偵測正是據此得知執行的成品仍與已核准的相符。若無法從某主機讀取容器，則顯示為未觀測，絕不假定其健康。因此，無 Docker 主機上的裸行程會被部署且其執行被記錄，但不會像容器化負載那樣被持續監測漂移。「一般伺服器」指在 Kubernetes 之外執行容器的伺服器——而非任意的非容器化行程。

不必。授權操作者自行放行。你提出一個限時的政策例外，走你設定的審批流程：具名審批角色、最少審批人數、原因代碼、佐證材料及任何補償性控制，並設最長有效期。自審批是你設定的開關，而非我們強加的預設值。

獲批的例外會翻轉那一條具體發現——抑制、延後、降級或要求某項控制——並連同誰在何時核准寫入該決策的稽核軌跡。它可用 DSSE 簽署，因此放行是可問責、可重播的，而不是從記錄中消失的靜默繞過。

有一條底線被刻意設為不可豁免：每個部署成品都必須帶有真實的掃描通過。例外解決某條具體政策發現；它絕不解除「該成品必須先被掃描」這一要求。

開箱狀態下，Stella Ops 維護自己的本機使用者，並使用 Argon2id 雜湊密碼。SAML、OIDC 與 LDAP/Active Directory 連接器隨平台簽署交付；啟用其中之一是操作者的設定步驟，而非預設值。安裝 bundle 為每個連接器各附有一個設定檔。

存取按租戶隔離並以權限為基礎，而不是粗放的角色劃分。平台提供 200 多個具名權限，因此要緊的動作都是各自獨立的授權：核准政策例外、繞過發布閘門、輪替金鑰加密金鑰，各自都是一項權限。你可以讓某人能讀取發現，卻無權解除攔截。

變更操作會記錄在產品自己的稽核軌跡中，並有其獨立的讀取權限——這獨立於發行所附帶的已簽署證據鏈，是在其之外的補充。這些都不受方案限制：免費版與授權版包含所有功能。

這問得對，我們不會迴避：簽章證明的是你的安裝產出了該判決，因此被攻陷的控制平面可以簽出一份看似有效的記錄。設計所做的，是讓這份記錄難以被盲目信任、且易被識破。

驗證依據你自己設定的信任根進行，缺失時直接失敗——它絕不呼叫任何 Stella Ops 服務來決定該信任什麼。每個判決都對你指定的時間戳機構加蓋時間戳，並可對你自己營運的透明日誌做包含性登記——於是「何時」與「是否曾被記錄」都錨定在受稽核的盒子之外。

最強的檢查是重播：每個判決都從其密封輸入重新計算，重算不出相同答案的記錄即失敗。在可疑控制平面無法掌控的基礎設施上重跑重播，偽造的判決便無法通過重算。這一切都不會讓被攻陷的平面變得無害——它把信任錨移出該平面，並給你一條獨立途徑來識破謊言。

沒有任何內容被刪除。可達性改變的是一條發現是否阻斷晉級，而不是它是否存在：該發現連同被賦予的狀態一併留在紀錄中，閘門證據會把發現的總數與真正造成阻斷的子集並列記錄。不存在需要事後還原的抑制步驟。

證據膠囊會說明原因和時間。它按摘要綁定產生該判決的每一項輸入：SBOM、公告快照、狀態所依據的可達性證據，以及作用於其上的政策識別碼和版本。促成該發行晉級的核准記錄在發行本身上，位於證據保管鏈的 Decision 階段。

而且它會重新計算。重播會在離線環境中依據這些封存輸入重新執行判決，並與記錄的結果比對，若不一致則回報差異；無法真正重新計算的重播會失敗，而不是把已存判決回拋給你。發生事故之後，決策當時已知的內容是有紀錄可查的事實，而不是爭辯的對象。

殘餘風險歸你。是你的政策決定了哪些狀態阻斷、哪些不阻斷，而閘門的價值不會高於其背後的政策。Stella Ops 主張的是該決策有證據支撐且可重播，從未主張該決策是正確的。在撰寫該政策之前值得知道：只有已證實的可達路徑才能阻斷發行，因為「未觀察到路徑」並不能證明路徑不存在，也不會被這樣記錄。

證據與稽核 → 可達性運作方式 →

裁決會重新開啟。安全公告的時效性不是一份事後才讀的報告——新的公告資料會重新評估已經做出的決策，受影響的發行會被標記。

週二正確的決策，到週四就可能不再正確，而您的部署環境中什麼都沒變。只在推進時評估的系統看不到這一點。

每個來源的資料時效都會在畫面上逐一顯示。資料是否過時始終可見，絕不隱藏。

一個在實體隔離環境中悄悄使用一個月前的公告資料、看起來卻一切正常的安裝，比拒絕啟動的安裝更糟。Stella Ops 會向您顯示其決策所依據資料的時效，而匯入 Offline Kit 時會記錄快照摘要，因此數個月後的重播使用的正是您當初決策時的資料。

稽核人員得到的是可以自行查核的東西，無須信任我們，也無須安裝任何軟體。已公開的範例膠囊只要用 cosign verify-blob 與 sha256sum，大約三十秒即可完成驗證。

• 掃描的內容（精確的產出物摘要）
• 發現了什麼（SBOM?軟體物料清單 - 軟體中所有套件和相依性的完整列表 + 可達性）
• 為何核准（政策判決）
• 由誰核准（已簽署的核准紀錄）

稽核人員可以獨立驗證簽名並使用 stella replay 離線重播決策。

產品主控台（v1.0-RC1）所示指令。

不需要。證據來自您現有建置作業中的 CLI。stella ci init 會產生管線步驟的骨架；CLI 會在作業中簽署建置證據（stella attest sign）。

不需要任何連接器——任何能執行二進位檔的 CI 都可以。Stella 使用的是已簽署的摘要與證據，而不是儲存庫存取權。

產品主控台（v1.0-RC1）所示指令。

合規包會將保管證據對應至 NIS2、DORA 與 CRA 義務。啟用後會以保守的僅證據模式開始收集證據；它並不聲稱符合法規要求。

營運者始終是受監管的決策者。Stella 協助您彙整並簽署監管機關預期的文件與產出物——它從不代為申報，也從不認證。

部分寫入路徑仍在開發中——例如，ENISA 自動提交傳輸仍待官方結構描述定案（目前由營運者放置於檔案系統）。每個合規包的現況都會在合規頁面上說明。

合規包詳細說明 →

您的安裝中一個環境裡的一個受控工作負載：容器服務，或透過 SSH 或 WinRM 部署到主機、以摘要定址的產出物；兩者計數方式相同。當 Stella Ops 部署、把關或推進某個工作負載的發行，掃描其已安裝的映像檔或產出物，或將先前的掃描結果套用於該已安裝的工作負載時，這個「工作負載–環境」關係即可計入。套用先前的結果不需要執行新的掃描。每個符合條件的關係只計一次，即使同時涉及其中多項活動。

部署位按安裝計數——一個安裝是 Stella Ops 控制平面的一次邏輯部署：同一部署中的叢集節點、資料庫複本與容錯移轉元件合併計算，獨立營運的安裝則各自分開計算。Stella Ops 本身的基礎架構從不計入。當該環境中對該工作負載的所有管理實際結束時，或工作負載已被移除且沒有其他管理活動使其維持有效時，部署位即告結束；掃描完成不會結束部署位，僅保存歷史證據或報告也不會產生、重新啟用或維持部署位。

目前的發行版本不顯示部署位總數。若 Stella Ops 部署、把關或推進某個工作負載的發行，掃描其已安裝的映像檔或產出物，或將先前的掃描結果套用於它，請將該工作負載在每個環境中各計一次。Estate 檢視列出 Stella Ops 執行過的部署；您還必須計入所有其他符合條件的工作負載，包括由其他工具部署的工作負載，以及自動清單未顯示的工作負載。

什麼算是受控部署位 →

不會。一個環境中某個工作負載的五個複本是一個部署位。在同一環境中重新啟動或重新部署同一工作負載，或推出其新的映像檔版本或摘要，都不會增加部署位。

三個。一個部署位是一個環境中的一個工作負載，因此在開發、預備與正式環境中執行的一個工作負載是 3 個部署位，十個工作負載分布在三個環境中就是 30 個。環境本身從不受限，也從不計價。

不會。掃描、重新掃描、漏洞報告、推進與部署都不另收費。掃描已安裝工作負載的映像檔或產出物，或將先前的掃描結果套用於它，可能使該工作負載在每個相關環境中計入部署位。每個「工作負載–環境」關係只計一次，不論掃描或報告的次數多寡。

僅將報告作為歷史證據保存或檢視，不會產生部署位。將先前的結果呈現為適用於某個已安裝工作負載的掃描資訊，即視為套用該結果。掃描未安裝在您任何環境中的映像檔或產出物，不會產生部署位。

每個安裝超過 20 個部署位的正式環境使用需要授權版：一份部署位容量至少等於您所管理部署位數量的授權。容量最多 100 個部署位時每月 $100，超出部分每個部署位容量每月 $1；超過 20 個後，每個部署位都計入——免費的 20 個不予扣除——因此容量為 30 個時每月 $100，200 個時為 $200。

容量增加自您訂購時生效，並自該日起按比例計費；容量減少則於續訂時生效。

如果您發現自己不慎超出了訂閱容量或免費的 20 個部署位，可自發現之日起繼續使用 14 天，期間縮減使用量或訂購容量。此寬限僅適用於意外情況，不適用於蓄意或反覆的超量使用。

現在即可訂閱：請寄送電子郵件至 sales@stella-ops.org，訂單將透過經授權的登記商戶成立。線上結帳即將推出。

費用是多少？ →

授權版有 $100 的每月最低收費，該最低收費涵蓋最多 100 個部署位：21 個部署位與 100 個部署位每月都是 $100。從 101 個部署位起，價格為每個部署位 $1——101 個為 $101，150 個為 $150。

不會有任何功能被停用。目前的發行版本不強制執行部署位上限，也不檢查授權，因此您的軟體、工作負載、掃描與部署都會繼續運作，每筆證據紀錄也仍可用您自己的信任根驗證。

不過，付費容量的授權僅限於訂閱期間。期限結束後，超過 20 個部署位的正式環境使用需要續訂，或將部署位縮減至 20 個或更少。

不需要。沒有授權伺服器、沒有啟用程序，也不回連：目前的發行版本不檢查授權，因此實體隔離的安裝與連線的安裝授權方式完全相同。您的免費使用由授權條款決定，付費容量由您的訂單決定——而不是由與我們的連線決定。

漏洞情資更新透過 Offline Kit 送達離線安裝，各資料來源的資料時效會逐一顯示在畫面上。

依您的訂單。授權版透過經授權的登記商戶購買，所購部署位容量至少須等於您所管理的部署位數量；經接受的訂單依 Stella Ops 客戶協議載明該容量與期限。

目前的發行版本不匯入也不檢查該紀錄，因此讓安裝維持在其範圍內是您的責任。期限結束時，軟體中不會有任何功能被停用，但此後超過 20 個部署位的正式環境使用需要續訂，或縮減至 20 個。

客戶協議 →

您的安裝產生的證據以您的安裝自己的金鑰簽署，而不是我們的金鑰。可攜式證據包可對照您宣告的信任根完全離線驗證：stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>。它會檢查總和檢查碼、資訊清單繫結與簽章，任一項未通過即判定失敗。

Stella Ops 的發行版本另行簽署：發行 bundle 與映像檔都以 Cosign 簽署，公開金鑰發布在驗證金鑰頁面上。發行簽章表明 bundle 來自我們；證據簽章表明紀錄來自您的安裝。

驗證金鑰 →

可以，透過與人員相同的介面。您執行的 CI 作業、指令碼或 AI 代理程式以 OAuth 用戶端認證服務用戶端的身分進行驗證，並透過發行 API 或 stella release approve|reject|promote|deploy|rollback 推動發行。核准與政策閘門由伺服器評估，因此自動化呼叫端與人員受同一政策約束。

其他掃描器也能接入：stella sbom upload 匯入外部 CycloneDX?業界廣泛使用的軟體物料清單（SBOM）開放標準格式 或 SPDX?軟體套件資料交換 - 另一種廣泛用於開源的SBOM開放標準格式 SBOM，並記錄產生它的工具；stella gate score batch --sarif 讓其他工具的 SARIF 發現項目通過同一個發行閘門。

一次審查針對一個明確界定的問題。工程師會分析您提供的資訊，並以書面工程回覆答覆：可能的原因，以及我們建議的矯正或診斷步驟。

它不包含無限工程工時、客製化開發、保證修復或持續顧問服務，也不附帶持續性的服務等級。購買前，我們會提供預估的交付時程；在取得所需資訊後，我們會在合理時間內以書面回覆。在要求您提供記錄檔之前，我們會告訴您如何安全地傳送診斷資料。如需購買，請寄送電子郵件至 support@stella-ops.org，並附上問題的簡短說明。

若審查顯示主要問題是受支援且設定正確的發行版本中可重現的缺陷，費用將予退還——若您偏好，也可改為抵用額度。

文件、Doctor 診斷與自助疑難排解對所有人免費；回報產品缺陷或安全漏洞從不需要付費審查。

Stella Ops 處於候選發布階段（v1.0-RC1）。

• 現在：v1.0.0-RC1-20261029——已簽署 bundle 與映像檔均為公開，可從 get.stella-ops.org 與 registry.stella-ops.org 匿名取得
• v1.0 發布之前：至少兩家客戶在正式環境中執行，且公開 API 表面凍結
• v1.0 預計於 2027 年元月 1 日發布
• 程式碼依 BUSL-1.1 以原始碼可取得方式提供
• 無論如何都不變：向下相容的證據格式與確定性重播

如何開始使用 →

目錄登入預設不啟用。LDAP、OIDC 與 SAML 外掛隨 v1.0.0-RC1-20261029 簽署交付，安裝 bundle 也為每個外掛附有一個設定檔，但 Stella Ops 不提供零設定的目錄登入：您需要將外掛指向您的目錄並加以啟用。

它也不是 Kubernetes 工具——這是刻意的定位，而非缺口。它不掃描惡意軟體，也不提供美國聯邦合規套件。如果其中任何一項是您的決定性需求，目前其他工具會更適合。

Stella 將發行建模為推進圖（Dev → Stage → Prod）。在每個閘門：

• 依據產出物的證據評估政策
• 核准以密碼學簽章記錄
• 為稽核產生一個 Decision Capsule?簽名的可匯出證據包，封裝發行決策的每個輸入和輸出，用於離線稽核和確定性重播

推進綁定的是產出物摘要，而不是標籤。相同摘要 = 重複使用相同證據。

Stella Ops 在歐洲開發，由一家在保加利亞註冊的公司營運；我們自己的基礎架構——本網站、映像檔倉庫與更新通道——託管於瑞士，瑞士已取得歐盟資料保護適足性認定。您的供應鏈中沒有總部位於美國的供應商。完整的營運者資訊請見法律聲明。

這個平台採自架方式，因此您的產出物、SBOM 與證據都留在您自己的基礎架構上——如有需要，也可以實體隔離。歐洲管轄加上自架，意味著持有您發行證據的只有您自己。

對於位在發行路徑中的任何元件，這都是合理的問題。設計層面的回答：日常運作從不依賴聯繫我們。產品自架、可在實體隔離環境中執行；沒有授權伺服器，也不依賴我們的雲端服務，而且目前的發行版本中沒有任何部分檢查授權，因此訂閱結束時不會有任何功能被停用——只是此後超過 20 個部署位的正式環境使用需要續訂，或縮減至 20 個。

您的證據同樣不需要我們。裁決與膠囊可離線驗證——stella replay 從密封輸入重新計算決策，全程不涉及任何 Stella Ops 服務或帳戶。

程式碼依 BUSL-1.1 以原始碼可取得方式提供：您可以閱讀、建置並修補所執行的版本。授權還內建期限——每個版本會在其 Change Date 轉為開放授權，目前版本最遲為 2030 年元月 20 日。日常維運您也不依賴我們：stella doctor 執行安裝的診斷檢查，stella doctor export 打包用於支援的診斷包，stella doctor fix 套用非破壞性修復。原始碼可透過聯絡頁面申請取得。

日常運作中，產品能自我支撐。Doctor 對整個堆疊做健康檢查，並針對發現的問題提供修復步驟；在維護視窗內，它會自行套用非破壞性修復，破壞性修復則只在核准閘門之後執行，並附帶試執行預覽與持久的稽核紀錄——否則就把手動步驟交給您。在此之上還能取得人工協助：以付費方式審查一個明確界定的問題，而不是靠它來維持您的安裝運作。如果您的採購需要合約化的持續性條款，請在評估期間與 sales@stella-ops.org 商定範圍。

驗證金鑰、已簽署的證據範例以及架構和強化文件均已公開，彙整在供應商安全審查頁面上，該頁面同時說明了我們的認證態勢。客戶參考案例即將推出——來自我們內部測試版的結果。盡職調查的討論範圍可在評估期間確定。

供應商安全審查 →

訂購、付款、稅務與開立發票由經授權的登記商戶處理——請參閱結帳說明。現在即可透過電子郵件下單：授權版請洽 sales@stella-ops.org，支援審查請洽 support@stella-ops.org。線上結帳即將推出。

產品的設計目標是無需工單也能持續運作：Doctor 會對整個堆疊做健康檢查，並在維護視窗內自行執行非破壞性修復，對於不會無人值守執行的項目則把確切步驟交給您。文件、Doctor 與自助疑難排解在每個方案中都免費。當您需要工程師時，一次支援審查針對一個明確界定的問題，費用為 $75：購買前您會先取得預估的交付時程，之後收到書面工程回覆；若主要問題確認為受支援且設定正確的發行版本中可重現的缺陷，費用將予退還。任何方案都不附帶持續性的服務等級。無論由誰回覆，都是打造產品的工程團隊——支援不外包。

Stella Ops Suite 依 BUSL-1.1 以原始碼可取得方式提供。您可以閱讀、建置並稽核程式碼。驗證層（膠囊驗證、簽章檢查）採用 Apache-2.0 授權。原始碼可透過聯絡頁面申請取得。

BUSL-1.1 允許每個安裝在最多 20 個受控部署位範圍內免費用於正式環境。超出該範圍，正式環境使用須採授權版，即依部署位數量授予的授權。在變更日期（Change Date，每次發行後四年）之後，程式碼會轉為 Apache-2.0 授權。

這種模式能為產品的持續開發提供資金，同時讓證據鏈保持完全可稽核。

租戶是一個隔離的工作空間，擁有自己的使用者、角色、政策與證據歷程。暫停一個租戶會凍結其所有存取權限。

多個租戶共用一個安裝；證據與存取權限依租戶分隔。這兩個詞回答的是不同的問題：

• Environment?邏輯部署目標（例如 dev、staging、prod），追蹤自己的發行歷史、推進規則與政策閘門（環境）是部署目標——發行在哪裡執行，以及由哪項政策為其推進把關。
• 租戶是存取與證據的邊界——誰能檢視與操作，以及證據歸入誰的證據歷程。

一個租戶通常包含多個環境。租戶與環境都不計價：定價計算的是整個安裝中的受控部署位。

可以。Stella 是您所用掃描器之上的控制層，其輸出都有落點：stella sbom upload 接收外部的 CycloneDX?業界廣泛使用的軟體物料清單（SBOM）開放標準格式 或 SPDX?軟體套件資料交換 - 另一種廣泛用於開源的SBOM開放標準格式 文件並記錄產生它的工具，stella gate score batch --sarif 則讓任何產出方的 SARIF 走與 Stella 自身掃描相同的發布關卡。

在這份發現清單之上，Stella 加上可達性分析、多簽發方 VEX?漏洞可利用性交換 - 關於漏洞是否在您的情境中實際可利用的機器可讀聲明、依環境區分的政策關卡，以及簽章證據匯出。您的掃描器找出 CVE；Stella 判定哪些真正重要，並為該判定提供證明。

可達性由 Stella 自己對該摘要的掃描計算得出。匯入的 SARIF 帶的是其產出方寫入的可達性值——Stella 讀取該欄位，並不重新推導。

產品主控台（v1.0-RC1）所示指令。

與 Trivy 對比 · 與 Snyk 對比 · 完整對比 →

Stella 不是您部署工具之上的一層——它本身就是發布協調器。Docker、Compose、SSH、WinRM、ECS、Nomad 和 Ansible 都是內建的執行外掛。在這些外掛涵蓋的目標上，部署由 Stella 自己完成，它不會去包裹一個已經在做這件事的工具。

您的 CI 原地不動，因為關卡只是一個可執行檔。任何能執行可執行檔的 CI 都可以呼叫 stella gate evaluate 並依退出碼作出反應。stella ci init 會為 GitHub Actions、GitLab CI 和 Gitea Actions 產生現成的流程；其他 CI 手寫幾行即可接上。

既有的連接器涵蓋 Gitea、GitHub App、GitLab、Jenkins、Harbor、Nexus、OCI?開放容器計畫 — 容器映像格式和登錄中心的業界標準 映像倉庫、Vault 和 Consul。實際的分工是：保留現有的 CI，再依環境決定由 Stella 執行部署，還是由 Stella 為您現有工具執行的部署把關。

產品主控台（v1.0-RC1）所示指令。

與 Octopus Deploy 對比 · 哪些需要接入，哪些不需要連接器 →

可以。合規計畫所引用、卻無法自行產出的產物層級證明，正是 Stella 提供的：對任一發布，部署了什麼、摘要是什麼、通過了哪條政策、由誰核准、在哪一天。這條紀錄讀自部署本身，並可從同一份證據確定性地重跑——明年得到的答案就是今天的答案。

這條紀錄以八種面向監管機關的簽章檔案匯出：NIS2 適用性聲明與有效性報告；DORA 資訊登錄冊、重大 ICT 事件報告、第 45 條資訊共享與 TLPT 證據包；CRA 技術文件與符合性檔案。每一份都經過封緘與簽章，可對照已公布的信任根離線驗證——核驗簽章完全不需要存取您的 Stella 執行個體。

您已經在跑的合規計畫無需做任何改動。每份匯出都是一個可攜帶的簽章檔案：把它附到它所證明的控制項上、交給稽核方，或透過保證匯出介面取回。而在匯出之前，就緒檢查會逐個檔案指出還缺什麼——缺口在您還來得及補的時候浮現，而不是在稽核當場。

合規領域現況，附來源 · 合規包詳解 →