ethan-andrews/threatintel-aggregator自托管威胁情报平台——支持情报源聚合、AI 分诊、MITRE ATT&CK 覆盖，以及与 Sentinel 集成的检测工程。可独立运行，也可与 Azure 完全集成。
一个自托管的威胁情报平台，聚合来自 60 多家安全厂商的 RSS 源，运行 AI 分类，将发现与您的 RunZero 资产清单进行关联，并通过深色模式 Web 仪表板呈现可操作的警报。
设计为可独立运行、零云依赖，或完全集成到 Azure/Entra/Sentinel 环境中——选择与您现有条件相匹配的层级。
| 层级 | 脚本 | AI 分类 | 认证 | 存储 | 您将获得 |
|---|---|---|---|---|---|
| 基础版 | scripts/setup-basic.sh | 关闭 | 本地 API 密钥 | 本地 Postgres (Docker) | 源聚合、IOC 提取、MITRE 矩阵、仪表板——无 AI、无云、无需注册任何服务 |
| 基础版 + API | scripts/setup-basic-api.sh | Anthropic（直连） | 本地 API 密钥 | 本地 Postgres (Docker) | 上述所有功能，外加 AI 严重性/TTP/摘要分类 |
| Azure + API | scripts/setup-azure.ps1 | Azure AI Foundry | Microsoft Entra ID SSO | 您自己的 Postgres（Azure Database for PostgreSQL 等） | 完整部署到 Azure Container Apps，支持按用户角色的 SSO。（detections.ai 管道集成将在未来版本中推出——见下文。） |
这三个层级运行完全相同的应用程序代码——唯一变化的是设置了哪些环境变量。完整参考请参见环境变量。```bash
./scripts/setup-basic.sh
./scripts/setup-basic-api.sh
./scripts/setup-azure.ps1
两个 bash 脚本会启动一个本地 Postgres 容器、应用 schema，并为你生成 `backend/.env` / `frontend/.env.local` —— 然后打印出实际启动应用的两条命令（`pip install` + 运行后端，`npm install` + 运行前端开发服务器）。`setup-azure.ps1` 是 `infra/provision.ps1` 的轻量封装，后者才是真正的 Azure Container Apps 部署运行手册。
---
## 功能特性
- **Feed 聚合** —— 按计划轮询 60+ 个 Tier 1/2/3 安全 RSS 源；自动去重并过滤推广内容
- **AI 分诊** —— 对每个条目进行分类，标注严重性（Critical/High/Medium/Low/Informational）、MITRE ATT&CK TTP 以及通俗易懂的摘要。提供商模块化：可直接使用 Anthropic API 或 Azure AI Foundry，通过一个环境变量即可切换，两种方式功能均无损失
- **IOC 提取** —— 自动从每个条目中提取 IP、域名、URL、文件哈希和 CVE
- **RunZero 集成** —— 同步你的资产清单，并将威胁情报与实时资产进行关联；基于 CVE、软件名称、操作系统版本和 IP 地址进行匹配。`RUNZERO` 下有三个子标签页：**Matches**（与你的清单关联的条目，可按严重性/日期/置信度/KEV 过滤）、**Exposure**（组织级别的已确认/可能暴露状态及修复跟踪）和 **Metrics**（随时间变化的摄入与修复趋势）
- **Your Stack** —— 定义你环境中的软件/操作系统；按相关性对所有条目重新评分
- **IOC 台账** —— 所有已提取指标的可搜索台账，包含条目交叉引用和 STIX/CSV 导出
- **MITRE ATT&CK 矩阵** —— 已摄入威胁情报中 TTP 覆盖范围的热力图
- **Feed 健康仪表盘** —— 每个 Feed 的轮询状态、连续失败跟踪以及 7 天文章量
- **Detections** —— 一个 9 标签页的审查界面（见下文），涵盖所有注册为检测的内容，无论是 AI 生成的、从你自己的文件导入的，还是从实时 Sentinel 工作区同步的
- **模块化认证** —— 支持基于角色的访问控制的 Microsoft Entra ID SSO，或使用单个共享本地 API 密钥且零 Azure 依赖。由前端自动检测；参见 [认证模式](#auth-modes)
### 两个与检测相关的功能
本仓库实际上在“detections”这一总括下提供了两个相关但可独立使用的东西：
1. **`DETECTIONS` 标签页** —— 一个自包含的审查界面，分为九个子标签页：
- **All Detections** —— 已注册分析规则的完整目录，可按技术/处置/审查状态过滤，每条均可展开查看其描述和完整 KQL。
- **Defender Custom Detections** —— 同一目录，但锁定为面向 Microsoft Defender for Endpoint 自定义检测规则而非 Sentinel 分析规则的检测。
- **Alignment Reviews** —— 每当一个检测分析规则针对某个 MITRE 技术注册时，AI 检查会将其实际覆盖范围与 MITRE 对该技术的自身描述进行比较。当出现偏差或仅部分覆盖该技术时，它会作为人工审查项出现在这里，附带 AI 的推理、建议的 KQL 修复以及该修复自身的验证结果（静态门禁 + 回测）—— 绝非盲目建议。
- **Disposition Alerts** —— 一个腐化检测队列：已批准的分析规则若其遥测衰减或其底层规则开始报错，会在此被标记以供重新审查，以其自身的检测名称命名，而不仅仅是共享的 MITRE 技术。
- **Generated Hunts** —— 检测被分组为 hunt（目前每个导入文件一个；一旦该集成上线，每个来源 TI 文章/detections.ai 项目一个），与 Microsoft Sentinel 自身的 Hunts 功能相匹配。一个 hunt 可以同步到真实的 Sentinel 工作区，作为 `Microsoft.SecurityInsights/hunts` 对象及其组成部分的已保存搜索查询（受 `SENTINEL_HUNTING_SYNC_ENABLED` 和 `mode` —— off/manual/auto —— 控制，可在 Settings > API Settings 中按团队配置；除非你选择加入，否则绝不会静默自动推送）。
- **Sentinel Hunts** —— 实际部署到你的 Sentinel 工作区 Hunting 功能中的实时清单，直接从 ARM 拉取，而非本应用自身的同步历史；包含可按查询测试/调优建议，你可以就地应用或忽略。
- **Sentinel Analytics Rules** —— 对 Microsoft Sentinel 的 Analytics Rules（`Microsoft.SecurityInsights/alertRules`）采用相同思路 —— 这是与 Hunting 不同的 Sentinel 资源类型，因为这些才是按计划实际触发事件/告警的规则 —— 并具有相同的调优建议应用/忽略工作流。
- **Local Detections** —— 参见下文 [在没有 Sentinel 或 AI 提供商的情况下运行](#running-without-sentinel-or-an-ai-provider-local-detections-import)。
- **Audit Log**（仅管理员）—— 本应用实际运行过的每一项检查的跨管道记录：AI 生成的检测门禁/控制探针结果、Sentinel hunt 同步尝试以及 Sentinel hunt 查询/分析规则测试运行，合并为一个分页、可过滤的列表 —— 刻意覆盖任何单一审查标签页都无法独自覆盖的内容。
完全在主后端内运行，审查界面本身无需额外部署。其自身的 API 设计刻意遵循下文 detections.ai 的约定，尽管它完全自包含。
2. **detections.ai 管道编排器 —— 即将推出。** detections.ai 正在开发一个用于 AI 辅助检测生成的公共 API，本仓库已为其构建了真实集成（`backend/detection_pipeline/orchestrator.py`），它接收已分诊的威胁情报，对照现有检测覆盖范围进行检查，并作为计划任务为你的 Sentinel 工作区生成 KQL 草稿。该集成将在 API 可用后支持它，目前尚未包含在此公开版本中。与此同时，**你完全不需要它就能使用 Detections 标签页** —— 下文 [Local Detections Import](#running-without-sentinel-or-an-ai-provider-local-detections-import) 为当今无 AI 生成和无 Sentinel 的设置覆盖了相同的“将真实检测引入本应用”目标。
### 在没有 Sentinel 或 AI 提供商的情况下运行：Local Detections Import
鉴于本应用的名称和主要卖点，**Basic** 层自托管用户最常见的问题大概是 *“我没有配置 Sentinel 或 AI 提供商 —— 我还能从 Detections/Hunts 标签页中得到任何东西吗？”* 答案是肯定的：将应用指向你自己检测规则文件的文件夹（手写的、从真实 Sentinel/Defender 租户导出的，或从公共 Sigma/Sentinel 规则仓库拉取的），它就会对它们进行编目、MITRE 标记和静态验证 —— 这一切都不需要 Sentinel 连接，也不需要 `DETECTIONS_AI_API_KEY`/Anthropic 密钥。
- **第一天支持的格式：** 原始 `.kql`/`.txt`/`.yar`/`.spl` 或任意扩展名的文件，每个文件可选配一个 `.json`/`.yaml` sidecar（`{"file": "myrule.kql", "title": "...", "description": "...", "technique_id": "T1059.001"}`）以提供元数据，而 Microsoft 自身的导出无需单独声明这些元数据；YARA；Suricata；Sigma YAML（单文档或多文档）；Splunk SPL；以及 Microsoft 自身原生导出的 Analytics Rule/Hunting Query JSON（只有 `Scheduled` 类型的规则携带本应用可评估的原始 KQL 查询 —— 其他所有类型都会被识别并报告，而非静默跳过）。
- **导入文件上实际运行的内容：** 对 KQL 内容进行静态验证（与 AI 生成路径使用的相同的持久性/发现引擎）；如果你*确实*配置了 AI 提供商，还会进行 MITRE 对齐检查（这是独立于 Sentinel 的一个维度 —— 你可以拥有其一、两者或都没有）；所有依赖 Sentinel 的内容（回测、遥测探针、处置跟踪）都不在范围内，并会显示为“未配置 Sentinel 连接”，而不是误导性的空白单元格。
- **它显示在哪里：** 导入的内容会成为普通的 hunt/检测行 —— 相同的表格、相同的审查工作流、相同的 MITRE 技术显示，与 AI 管道生成的任何内容一样 —— 因此它也会出现在常规的 `ALL DETECTIONS`/`GENERATED HUNTS` 视图中，而不仅仅是它自己的标签页。专用的 **Local Detections** 子标签页（位于 `DETECTIONS` 下，仅管理员可触发导入）是你将其指向文件夹并查看每个文件进度/结果的地方。
- **设置：** 将 `LOCAL_IMPORT_DIR` 设置为后端文件系统上的绝对路径（在容器部署中为挂载卷）—— 所有导入内容都必须位于该根目录下；UI 允许你在其下选择子路径，而绝不是任意文件系统位置。参见 [环境变量](#environment-variables)。
- **立即试用：** `examples/local-detections-samples/` 附带一个小的即用型导入文件夹 —— 两条有效的 KQL 规则（其中一条配有 `.json` sidecar 以展示该机制）、一条故意无效的规则（以查看标记为无效的横幅）以及一个无法识别的文件（以查看导入失败的横幅）。将 `LOCAL_IMPORT_DIR` 指向它，即可在你的首次导入中看到全部三种结果状态，无需编写规则。
**Local Detections** —— 一次完成的导入运行：摘要横幅会指出那些已被编目但被静态分析标记为无效的文件（此处是一条针对单个硬编码哈希告警的规则），与那些干净导入的文件并列显示，并且每个文件都会成为下方普通的 hunt/检测行
---
## 截图
以下所有截图均使用为文档生成的合成数据（虚假组织名称、RFC 5737 示例 IP、`.example` 域名）—— 不包含真实威胁情报或客户数据。
**Feed** —— 浏览和过滤已分诊的威胁情报条目，包含严重性、标签、IOC 和 TTP
<br>
**Dashboard** —— 一目了然的严重性分布和顶级 MITRE ATT&CK 技术
<br>
**MITRE ATT&CK** —— 已摄入情报中技术覆盖范围的完整矩阵热力图