Fathometer — CVE 情报

为您自己运维的 root 服务器提供的自托管 CVE 情报。
Agent 在每台主机上运行 Trivy，Fathometer 结合上下文使用 LLM 评估每一个发现，并仅筛选出那些真正需要您关注的项。
可以把它想象成 uptime-kuma，只不过它专注于运行中服务器的 CVE。

适合你吗？ • 功能 • AI 做了什么 • 它是如何评分的 • 工程设计 • 安装 • 完整规范

只有三个页面，仅此而已。一个机群仪表板、一个按主机划分的分流工作区， 以及一个跨主机发现结果浏览器 —— 没有庞杂的菜单，也没有 套娃式的仪表板。

     

_{服务器详情 · 发现结果 · 上游检查 · CVE 聊天 —— 点击放大}

## 适合你吗？ **如果满足以下条件，它就是为您量身打造的：** - 您运维着少量由自己管理的**普通 root 服务器 / VPS**； - 您想知道一台主机报告的数百个 CVE 中，究竟有哪些*对该主机真正重要*，而不是纸上谈兵； - 您想要一款安静、**自托管、单用户操作**的工具 —— 没有 SaaS，无需账号，数据也不会离开您的基础设施，且对气隙隔离友好。 **如果您符合以下情况，请另寻他法：** - 需要扫描**容器镜像、Kubernetes 集群或 CI pipelines** —— 直接使用 Trivy / Grype 或专门为此构建的平台； - 需要**多用户 RBAC、SSO 或通知**（电子邮件 / Slack / webhooks）； - 需要带有 SLA、工单系统和移动端仪表板的企业级漏洞管理。 ### 概览 | | | |---|---| | **技术栈** | Python 3.13 · Flask · PostgreSQL 17 · HTMX + Alpine.js · 纯 CSS | | **扫描器** | Trivy 文件系统扫描，轻量级 agent 推送模型 | | **LLM** | 任何兼容 OpenAI 的 endpoint —— 自带密钥 | | **部署** | docker-compose（也可使用 Kubernetes；一体化镜像已在路线图中） | | **模式** | 单用户 · 自托管 · 支持气隙隔离运行 | | **许可** | Apache-2.0 | ## 功能 - **两级分流机制** —— 只有 **Act** 和 **Escalate** 会推送到您面前；*Watch* 和 *Noise* 会被隐藏在后台。没有海量警报轰炸，也不需要手动在海量“严重”CVE 中艰难筛选。 - **真实的补丁，而非幻影** —— Fathometer 能够分辨出哪些是您*可以真正应用*的修复（`dnf`/`apt upgrade` 会拉取它），哪些是仅存在于上游静态链接二进制文件（Go、Rust、Java）中且需要供应商重新构建的修复。它会将每个二进制文件解析到其所属的包，并检查您主机的 repos，因此它绝不会要求您为一个包管理器中尚不存在的补丁去“应用更新”。 - **Agent 推送模型** —— 轻量级 agent 在每台主机上运行 Trivy 并推送结果；Fathometer 永远不需要您服务器的凭证，并且支持气隙隔离环境运行。 - **uptime-kuma 风格的概览** —— 提供带有每台主机心跳历史的平稳机群视图，而不是令人眼花缭乱的指标仪表板。 - **一键接入** —— 使用单条 root 命令即可注册或移除主机（支持每日 systemd timer，cron 作为备选）。 - **自托管且单用户** —— 您的扫描数据永远不会离开您的基础设施。专为亲自运维服务器的操作者设计 —— 在架构上杜绝了电子邮件 / Discord / webhook 的噪音干扰。 ## AI 做了什么 Fathometer 让 LLM 专注于**三项**工作。每一项工作都会连接到*您自己*兼容 OpenAI 的 endpoint 和密钥，它们各司其职，且都不会在没有您允许的情况下擅自越权更改 —— AI 只提供建议，由您来做决定。 ### 1 · 上下文审查器 每个发现都会由审查器读取，它会像人类分流员一样提出问题：在该主机上这是否**可达**？部署是否真的运行了**易受攻击的代码路径**？攻击者能否满足**前置条件**？如果满足，造成的破坏有多严重？CVSS、EPSS 和 KEV 仅作为*权重*输入，绝不作为最终判决。结果将归为四个级别之一 —— **Escalate · Act · Watch · Noise** —— 并且每一次降级都会明确说明*缺少了哪个*条件，以便您进行核实。每个判决结果都会被缓存，因此您只需为*新*发现向 LLM 付费。[详细了解评分机制 →](#how-it-scores) ### 2 · 自动化上游检查  _{(可选择开启)} 对于静态链接的二进制文件（Go、Rust、Java）和手动安装的程序（Ansible、GitHub releases），您主机的包管理器根本无法告诉您是否已经有了修复方案。只需按下一个按钮，agent 就会去为您查找：它会搜索项目的最新 releases，阅读构建清单（例如 `go.mod` 工具链），并用一句话回答是否已经有了修复的构建版本 —— 以及具体的版本号。帮您省去了手动查阅 changelog 和挖掘 `go.mod` 的麻烦。它是**仅供参考的**（绝不会自行更改风险级别），**仅在您需要时运行**（绝不在扫描路径中运行），并且**默认关闭**。您可以自带搜索后端 —— 自托管的 SearXNG、Tavily、Firecrawl 等 —— 而气隙隔离部署只需移除该容器即可。 ### 3 · CVE 聊天 有时候您只是想理清头绪。任何包组上的 **Help** 按钮都会打开一个仅针对该特定主机和包组的聊天上下文：您可以让它解释**攻击向量**、实际的爆炸半径、该优先修补什么，或者评估推迟修补是否安全。它会根据一个聚焦的快照来回答 —— 即该组最重要的发现加上其余部分的汇总，而不是直接倾倒原始数据 —— 因此回复不仅迅速，而且始终立足于*您自己的*主机，而非通用的 CVE 套话。 ### 成本如何 出乎意料地低。每个发现仅评估一次并缓存判决，因此您只需为*新*发现支付 LLM 费用，而无需为每次扫描买单。如果在普通推理提供商上使用像 **`gpt-oss-120b`** 或 **`deepseek-v4-flash`** 这样的开放权重模型，评估数千个发现的成本通常在**几美分**以内，而典型情况下一天内*新*发现的成本**约为一美分**。您自带兼容 OpenAI 的 endpoint 和密钥，因此服务商和开销完全由您掌控。 ## 开发动机 市面上已经有大量针对容器镜像、Kubernetes 集群和 CI pipelines 的工具。而让您轻松掌控手头那几台**普通的 root 服务器** —— 从而安然入睡 —— 正是 Fathometer 致力于填补的空白。 一台 root 服务器很容易就会吐出数百个 CVE，但在*您的*特定环境中，几乎没有任何一个是可利用的。手动去筛选这些信息不仅耗时数小时，还会让您逐渐对警报麻木。Fathometer 的存在，就是为了将这份冗长的清单精简到您主机上真正具有意义的极少数发现上。 它是一款实用的日常工具，**并非完美无缺**，也无法取代企业级的漏洞管理 —— 但它总好过盲目地应用每一个发行版的补丁，或者把时间浪费在那些根本无法利用的发现上。 ## 它是如何评分的 Fathometer 从两个维度对每个发现进行评估，并将其归入四个级别之一。 **维度 1 —— 在这台主机上是否可利用？** 必须同时满足以下三个条件： - **可达** —— 攻击者能否接触到该服务？ - **代码路径** —— 当前的部署是否真的运行了易受攻击的代码？ - **前置条件** —— 攻击者能否满足漏洞利用所需的条件（如认证、配置、输入）？ 哪怕只少一个，CVSS 分数也就毫无意义了 —— 它在这里根本无法被利用。 CVSS、EPSS 和 KEV 仅作为*权重*引入，绝不作为最终判决。 **维度 2 —— 破坏程度如何？** 从代码执行/接管，到数据窃取和篡改，再到单纯的服务崩溃。 由此得出四个级别： - **Escalate** —— 可利用*且*非常严重（如接管、数据丢失）。立即采取行动。 - **Act** —— 可利用但破坏有限，或者虽然严重但仅有理论上的可达性。在正常的维护周期内进行修补。 - **Watch** —— 存在但在该环境下不可达（例如功能已被禁用），尽管评分很高。 - **Noise** —— 该组件根本没有在这台主机上运行（只是作为一个文件静静躺在那里）。 每一次降级都会明确说明缺少了哪个条件，以便您进行核实。 纯粹的 DoS 永远不会自动升级为高危 —— 最坏的情况也不过就是重启服务。 ## 经久耐用 Fathometer 就像您愿意托付自己服务器的基础设施一样可靠 —— 它绝不是周末随手做的原型项目： - **经过充分测试。** 超过 2,950 个纯单元测试在每次更改后都能顺利通过，并在 CI 中强制执行了覆盖率底线。完整的 lint → type-check → test 检查关卡在每次推送和 pull request 时都会运行（即上方的 CI 徽章）。 - **端到端类型化。** 整个应用程序全面应用了 `mypy --strict`，并且通篇使用了 Pydantic v2 和 SQLAlchemy 2.x。代码 Lint 和格式化通过 Ruff 强制执行。 - **有据可查的决策。** [`docs/decisions/`](docs/decisions/) 中的 60 多份架构决策记录（ADR）记录了每一个重要的选择及其背后原因 —— 绝不让任何重要事项留下猜测的余地。 - **版本控制。** 采用语义化版本控制，并维护着 [`CHANGELOG.md`](CHANGELOG.md)，同时在 [`ARCHITECTURE.md`](ARCHITECTURE.md) 中提供了单一、完整的规范。 - **设计上高度重视安全。** 不受信任的扫描器和 LLM 数据已使用 `nh3` 进行净化处理，且绝不使用 `|safe` 进行渲染；LLM API 密钥在静态存储时已加密（Fernet），密码使用 Argon2 进行哈希处理，endpoint 受到速率限制，且可选择的出站研究路径受到 SSRF 防护。完整的威胁模型位于 [`ARCHITECTURE.md`](ARCHITECTURE.md)。 ## 安装 Fathometer Fathometer 的核心组件非常精简。有三种方式可以运行它。

1. docker-compose —— 目前推荐

这是目前官方支持的方案。它会拉起应用程序、一个 PostgreSQL 17 数据库，以及 LLM worker。建议在前端部署反向代理（Caddy、nginx 或 Traefik）来处理 TLS —— 应用程序在 8000 端口上使用纯 HTTP 通信，**绝不打算**直接暴露在公网中。 ``` cp .env.example .env # 生成所需的两个 secrets 并将它们粘贴到 .env 中： python -c "import secrets; print(secrets.token_urlsafe(48))" # FM_ENCRYPTION_KEY python -c "import secrets; print(secrets.token_urlsafe(48))" # FM_SECRET_KEY # 将 FM_PUBLIC_URL 设置为您的外部 HTTPS URL，例如 https://fathometer.example.com docker compose up -d --build curl -fsS http://localhost:8000/healthz # expects {"status":"ok"} ``` 反向代理配置、TLS、`/api/scans` IP 白名单以及 Postgres 备份的相关内容，已在 [`ARCHITECTURE.md`](ARCHITECTURE.md) 第 9 节中介绍。

2. Kubernetes —— 勇敢者的选择

像运行任何普通的 Flask + 数据库工作负载一样运行应用程序和 Postgres，并让您的 ingress controller 终止 TLS。这不太可能是大多数人的选择，但 Fathometer 的架构对此没有任何阻碍。

3. 一体化单容器 —— 路线图中

提供一个自包含的独立镜像（应用 + 数据库打包在同一个容器中，uptime-kuma 风格，类似 GitLab Omnibus），以实现最简单的部署设置。**目前尚未发布** —— 仅为计划中。在此之前，请使用 docker-compose。

## 配置 LLM provider —— 必须的首要步骤 Fathometer 发布时**不附带**任何模型。上下文审查器是整个工具的核心引擎，因此一旦应用程序启动，您的**第一步**就是将其指向一个 LLM：打开 **Settings → LLM provider**，设置兼容 OpenAI 的 base URL，粘贴您的 API 密钥（静态加密保存），然后选择一个模型。**在配置好 provider之前，审查器无法运行，也不会对任何发现结果进行评估** —— 应用程序虽然启动了，但会一直处于闲置状态。 任何兼容 OpenAI 协议的 endpoint 都可以使用（DeepInfra、您自己的 vLLM/Ollama 等）；有关模型和成本的指导，请参阅 [AI 做了什么](#what-the-ai-does)。 ## 添加服务器 一旦可以通过 HTTPS 访问 Fathometer，请使用 root 权限运行单条命令来注册每台 root 服务器。它会安装 Trivy 和 agent，使用您的主密钥（交互式提示输入）注册主机，验证 Trivy 官方发布版的合法性，并设置每日的扫描定时器（systemd，cron 作为备选）。 ``` sudo bash <(curl -fsSL https://fathometer.example.com/install.sh) ``` 重复运行相同的命令会更新现有的主机，并跳过主密钥的输入提示。对于无人值守的自动化配置（Ansible、cloud-init），请通过环境变量传入 `FM_UNATTENDED=1` 以及 `FM_MASTER_KEY` / `FM_SERVER_NAME`。 支持系统：Debian/Ubuntu，RHEL 系列（AlmaLinux、Rocky、Fedora、Amazon、Oracle），SUSE —— 支持 `x86_64` 和 `aarch64` 架构。不提供对 Alpine/OpenRC 和容器主机的支持。 ## 移除服务器 要从主机上卸载 agent，请运行它在安装时释放的卸载程序（支持气隙隔离环境，无需后端）： ``` sudo /opt/fathometer/bin/fathometer-uninstall.sh ``` 或者，与安装程序相对应，您也可以通过网络进行卸载： ``` sudo bash <(curl -fsSL https://fathometer.example.com/uninstall.sh) ``` 它会移除 `/opt/fathometer`、`/etc/fathometer`（包含配置和 API 密钥）、systemd 定时器/服务（或 cron 条目）以及 Trivy 缓存。您可以传入 `--keep-cache` 来保留 Trivy 数据库，或者传入 `-y` / `FM_UNATTENDED=1` 来跳过确认提示。这只是本地清理 —— 直到您在仪表板中手动删除之前，该主机依然会显示在列表中。 ## 文档与贡献 - [`ARCHITECTURE.md`](ARCHITECTURE.md) —— 规范说明书：包含部署细节、反向代理和 TLS、安全模型、数据模型以及评分的内部实现。 - [`CHANGELOG.md`](CHANGELOG.md) —— 记录每个版本的变更内容。 - [`docs/decisions/`](docs/decisions/) —— 架构决策记录（ADR）。 - [`CONTRIBUTING.md`](CONTRIBUTING.md) —— 如何提出变更建议（适用 CLA）。 ## 许可 Fathometer 基于 Apache License, Version 2.0 授权。有关完整文本请查阅 [`LICENSE`](LICENSE)，归属说明请查阅 [`NOTICE`](NOTICE)。 第三方依赖许可 —— 包括 psycopg 的 LGPL-3.0 声明 —— 列于 [`THIRD-PARTY-NOTICES.md`](THIRD-PARTY-NOTICES.md) 中。 版权所有 2026 [THEKROLL LTD](https://thekroll.ltd)。

_{THEKROLL LTD · human intent. machine precision.}

标签：CVE分诊, GPT, LLM分析, Python, 无后门, 漏洞管理, 自托管, 请求拦截