日志、指标与追踪
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 写入的审计账本相互独立。