日誌、指標與追蹤
OpenTelemetry / OTLP
從您已在執行的系統中採集日誌、指標和程式碼
日誌分散在十幾個工具中，彼此毫無關聯。等到有人注意到其中的規律時，根本問題可能已經持續了數小時。
依賴項掃描器只會告訴您哪些存在漏洞，卻不會告訴您修復是否可以安全上線、該漏洞此刻是否正被利用，或者組織內還有什麼依賴同一個軟體包。
沒有人會手動維護最新的服務地圖，因此要把一個緩慢的請求追溯到導致問題的主機或依賴項，就得在從未設計為互通的多個儀表盤之間來回切換。
安全審查發生在定期審計中，而不是每次推送時。本可被審查者發現的問題就這樣直接上線到生產環境。
每個已連線的程式碼倉庫都會在每次推送時以及每天掃描一次存在漏洞的依賴項。每項發現都會給出需要修復的確切檔案和行號，並在您升級之前提供相容性風險報告，包含 0–100 的安全評分，以及對依賴同一軟體包的其他所有倉庫的影響範圍。隨後，Threat Intelligence 會將每項發現與 CISA 的 Known Exploited Vulnerabilities (KEV) 目錄和 FIRST.org 的 EPSS 漏洞利用預測評分交叉比對，因此正在真實世界中被積極利用的 CVE 會被立即標記，而不是淹沒在僅按 CVSS 排序的數百項佇列中。每次提交到已連線倉庫的程式碼也會獲得自動的 LLM 程式碼審查，在問題上線之前將其揭示出來。
通過 OpenTelemetry 採集日誌、主機指標和分散式追蹤，包括為 EKS、GKE 和 AKS 生成的 OTel Collector Helm 安裝包。Live Logs 即時顯示每個事件，並提供級別、來源和全文過濾；Metrics 按主機跟蹤 CPU、記憶體、磁碟和網路；Traces 呈現各服務的延遲和錯誤率；Service Map 則根據已接入的追蹤資料自動構建，讓您無需手動繪製，就能看到誰呼叫了誰，以及當前哪裡出了問題。
使用一行 GitHub Action 或簡單的 curl/jq 指令碼，從任意測試執行器上傳 lcov 報告——Jest、pytest-cov、Go 的 gcov2lcov，以及任何其他可輸出 lcov 的工具。SOC 會持續跟蹤每個倉庫的行覆蓋率變化，因此覆蓋率一旦下降就會立刻顯現，而不必等到下一次定期審計。
部署 OTel Collector 以採集日誌、主機指標和追蹤——生成的 OTel Collector Helm 安裝包支援 EKS、GKE 和 AKS。連線 GitHub 以獲取部署、推送和工作流執行記錄。
日誌、指標和追蹤會立即出現在 Live Logs、Metrics 和 Traces 中，可搜尋、可過濾、可匯出，同時 Service Map 會根據實際流動的流量自動繪製。無需先搭建任何儀表盤。
告警由日誌量和規則匹配觸發。CVE Radar 會在每次推送時以及每天掃描一次，隨後 Threat Intelligence 將發現與 CISA KEV 和 FIRST.org EPSS 交叉比對。每次提交還會獲得自動的 LLM 程式碼審查——您無需編寫任何檢測規則。
將 obiguard-coverage-upload-action（或簡單的 curl/jq 步驟）新增到任何已生成 lcov 報告的工作流中，SOC 便會在每次執行時跟蹤該倉庫的行覆蓋率趨勢。
每條告警、CVE 發現、威脅匹配和程式碼發現都會按嚴重程度評分並排序——已被在野利用的 CVE 優先，並附帶確切的檔案和行號以及升級安全評分——讓您的團隊知道下一步該處理什麼。
每條告警、CVE 發現、威脅匹配和程式碼發現都會保留歷史記錄，而不是在被確認後就消失的告警。這是 SOC 自身的審計追蹤，與 Governance AI 寫入的審計賬本相互獨立。