cpt-ferna02/AVEN

GitHub: cpt-ferna02/AVEN

AVEN 是一个自主运行的漏洞情报 pipeline,通过多因子风险评分模型帮助安全团队从海量 CVE 中筛选出真正需要优先处理的高危漏洞。

Stars: 0 | Forks: 0

# ⚡ AVEN ### 自主漏洞与利用通知引擎 [![Python](https://img.shields.io/badge/Python-3.10+-blue)](https://python.org) [![License](https://img.shields.io/badge/License-MIT-green)](LICENSE) [![Status](https://img.shields.io/badge/Status-Active-brightgreen)]() AVEN 是一个自主运行的漏洞情报 pipeline,专为需要超越普通 CVE 订阅源的安全工程团队而构建。它持续从 National Vulnerability Database 和 CISA 的 Known Exploited Vulnerabilities 目录中提取漏洞,在公开的漏洞利用代码库中搜寻 PoC 证据,并通过自定义的多因素优先级模型对每个 CVE 进行评分。其输出包括实时风险仪表板、自动生成的 Sigma 检测规则以及 Slack 警报——所有这些都基于 6 小时的自主计划运行,无需人工干预。 本项目从零开始构建,作为安全工程毕业设计的作品集项目。每个组件——评分引擎、搜寻逻辑、关联系统——都是手动设计和实现的。没有使用任何预构建的漏洞管理框架。 ## 仪表板预览 ![AVEN 仪表板概览](https://static.pigsec.cn/wp-content/uploads/repos/2026/06/eef0a5aa54133404.png) ## AVEN 存在的意义 安全团队正淹没在 CVE 之中。NVD 每周发布数百个新漏洞,但仅靠 CVSS 分数并不能作为良好的分流信号。一个 CVSS 9.8 的漏洞如果没有公开的 PoC 且未暴露资产,其紧迫性反而不如一个 CVSS 7.0 但存在于 CISA 的 KEV 列表中、在 GitHub 上有武器化 PoC 且影响三台生产服务器的漏洞。 构建 AVEN 正是为了解决这一痛点。它将漏洞利用情报、被利用概率、资产上下文以及确认的实际攻击活动结合到一个单一的优先级风险评分中,使安全工程师能够将时间花在真正重要的漏洞上。 ## 架构 ``` ┌─────────────────────────────────────────────────────────────────┐ │ AVEN Pipeline │ │ │ │ NVD API ──────────┐ │ │ CISA KEV ─────────┤ │ │ GitHub Search ────┼──▶ Ingestion ──▶ Hunting ──▶ Maturity │ │ ExploitDB ────────┤ Classifier │ │ EPSS API ─────────┘ │ │ │ ▼ │ │ Asset Inventory ──────────────────────▶ Scoring Engine │ │ │ │ │ ┌───────────────────┤ │ │ ▼ ▼ │ │ Dashboard Reports + │ │ (FastAPI) Sigma Rules │ │ │ │ │ │ └────────┬──────────┘ │ │ ▼ │ │ Slack Alerts │ │ │ │ Scheduler (every 6 hours) ──▶ Runs entire pipeline │ └─────────────────────────────────────────────────────────────────┘ ``` ## 评分引擎 AVEN 的核心是一个自定义的多因素风险优先级模型。每个 CVE 都会根据五个加权因素获得一个 0 到 100 的分数: | 因素 | 权重 | 来源 | 原理 | | ------------------ | ------ | ------------------ | -------------------------------------- | | CVSS 基础分数 | 30% | NVD | 既定的严重性基准 | | EPSS 概率 | 25% | FIRST.org | 未来 30 天内的被利用可能性 | | 漏洞成熟度 | 25% | GitHub / ExploitDB | 实际的攻击者能力 | | CISA KEV 成员资格 | 10% | CISA | 已确认的实际攻击活动 | | 资产暴露程度 | 10% | 内部资产清单 | 环境上下文 | **漏洞成熟度**根据公开证据分为四个级别: | 级别 | 定义 | | ------------- | --------------------------------------------------------------- | | `THEORETICAL` | 存在 CVE,但未找到公开的漏洞利用代码 | | `POC` | 在 GitHub 或 ExploitDB 上发现了 PoC 代码 | | `WEAPONIZED` | 有多个 PoC 来源或高星标数——处于活跃开发状态 | | `ACTIVE` | 被列入 CISA KEV——确认在现实攻击中被利用 | 最终分数映射到相应的风险级别:**CRITICAL** (≥80)、**HIGH** (60–79)、**MEDIUM** (40–59)、**LOW** (<40)。 这些权重可以在 `config.yaml` 中完全配置。这是一个深思熟虑的设计决定——不同的组织有不同的风险容忍度,金融机构对资产暴露程度的加权方式将不同于初创公司。 ## AVEN 的产出 **高管报告** — 包含漏洞修复优先级指导的通俗语言顶层漏洞摘要。专供非技术背景的利益相关者阅读。每次运行时会生成带有时间戳的文本文件。 **工程师报告** — 针对每个高优先级 CVE 的完整技术 JSON 输出:CVSS 向量、EPSS 概率、MITRE ATT&CK 映射、带链接的 PoC 证据、受影响资产以及评分明细。 **Sigma 规则** — 为每个高优先级 CVE 自动生成的有效 Sigma YAML 格式检测规则,映射到 MITRE ATT&CK 技术,随时可导入任何兼容的 SIEM(Splunk、Elastic、Wazuh、Chronicle)。 **实时仪表板** — 显示实时风险评分、级别分布的 Web 界面,带有 PoC 链接和资产匹配、MITRE 映射以及运行历史的 CVE 详情面板。 ![CVE 详情面板](https://static.pigsec.cn/wp-content/uploads/repos/2026/06/74b46adaba133410.png) **Slack 警报** — 在每次 pipeline 运行时发送到配置的频道,包含摘要以及针对新 CRITICAL 和 HIGH CVE 的单独警报。 ![Slack 警报](https://static.pigsec.cn/wp-content/uploads/repos/2026/06/25ad75b828133419.png) ## 项目结构 ``` AVEN/ ├── core/ │ ├── ingestion/ # NVD + KEV fetchers, SQLite schema │ ├── hunting/ # GitHub hunter, ExploitDB hunter, maturity classifier │ ├── scoring/ # EPSS fetcher, risk scoring engine │ ├── correlation/ # Asset correlator │ └── reporting/ # Executive report, engineer report, Sigma generator ├── scheduler/ # Autonomous run loop (schedule library) ├── dashboard/ # FastAPI backend + single-file HTML frontend ├── alerts/ # Slack webhook integration ├── data/ │ ├── mock_assets.json # Asset inventory │ └── db/aven.db # SQLite database ├── output/ # Timestamped reports and Sigma rules per run ├── config.yaml # All configuration in one place ├── main.py # Single-run entry point └── requirements.txt ``` ## 快速开始 ``` git clone https://github.com/cpt-ferna02/AVEN.git cd AVEN python3 -m venv venv source venv/bin/activate pip install -r requirements.txt cp .env.example .env # 在 .env 中填写 NVD_API_KEY 和 GITHUB_TOKEN python3 main.py ``` **运行仪表板:** ``` python3 dashboard/api.py # 打开 http://localhost:8000 ``` **自主运行:** ``` nohup python3 scheduler/runner.py > output/aven.log 2>&1 & ``` ## 配置 所有设置都位于 `config.yaml` 中: | 设置 | 默认值 | 描述 | | ---------------------------------- | ------ | --------------------------------- | | `nvd.days_back` | 7 | 每次运行提取的 CVE 历史天数 | | `scheduler.run_every_hours` | 6 | Pipeline 运行间隔 | | `scoring.weights.cvss` | 0.30 | CVSS 组成部分权重 | | `scoring.weights.epss` | 0.25 | EPSS 组成部分权重 | | `scoring.weights.exploit_maturity` | 0.25 | 成熟度组成部分权重 | | `scoring.weights.kev_bonus` | 0.10 | KEV 成员资格加分 | | `scoring.weights.asset_exposure` | 0.10 | 资产匹配加分 | ## 环境变量 ``` NVD_API_KEY= # Free at nvd.nist.gov/developers/request-an-api-key GITHUB_TOKEN= # Personal access token, public_repo scope only SLACK_WEBHOOK_URL= # Optional — incoming webhook URL for alerts ``` ## 工程挑战与解决方式 构建 AVEN 涉及几个实际的工程问题,需要诊断和刻意的修复。此处记录这些问题是因为它们反映了系统的实际运行方式,而不仅仅是设计初衷。 **NVD 速率限制与无限循环** — 最初的 NVD 抓取器包含一个分页循环,当遇到 429 速率限制响应时,无法推进页码索引,从而在同一偏移量上无限循环。修复此问题需要添加带有指数退避(30秒、60秒、90秒)的重试机制,以及在重试耗尽时的硬中断条件。现在,抓取器能够优雅地处理速率限制并正确恢复。 **GitHub Token 未加载** — 在 `.env` 中设置 API 密钥后,NVD 密钥和 GitHub token 在运行时均返回 NOT FOUND。根本原因是 `.env` 文件在清理过程中被意外提交到 git 并随后删除,导致该文件在磁盘上完全丢失。通过重新创建该文件并使用针对性的 Python 测试验证密钥加载后,问题得以解决。 **密钥暴露与 Git 历史重写** — 在一次早期推送中,GitHub token 被意外提交在 `.env` 内部。GitHub 的推送保护功能正确地拦截了这次推送。该 token 被立即吊销,生成了新 token,并使用 `git filter-branch` 重写了提交历史,在强制推送干净的历史之前从所有历史提交中清除了该密钥。 **重复的评分行** — 每次运行时,scores 表都会为每个 CVE 生成重复行,因为 `INSERT OR REPLACE` 需要在目标列上有 UNIQUE 约束才能作为 upsert 生效。如果没有它,SQLite 会将每次插入视为新行。通过在 scores 表 schema 的 `cve_id` 列添加 `UNIQUE` 并重新创建数据库解决了该问题。 **数据库 Schema 语法错误** — 在一次 schema 更新期间,格式错误的列定义(`cve_id TEXT UNIQUE, PRIMARY KEY`)导致了 SQLite 语法错误,阻碍了数据库的初始化。通过理解在 SQLite 中 `PRIMARY KEY` 已经隐含了唯一性来修复——这两个约束在同一列上是互斥的。 **`save_cves` 嵌套在 `fetch_recent_cves` 内部** — 在替换 NVD 抓取器函数时,`save_cves` 函数被意外粘贴到了 `fetch_recent_cves` 内部,而不是模块级别。由于调用点无法访问嵌套函数,Python 在运行时抛出了 `NameError`。通过使用 heredoc 干净地重写整个文件以避免缩进歧义来修复。 **venv 被提交到 Git** — Python 虚拟环境目录在第一次推送时被提交,使仓库膨胀到了 28MB。使用 `git rm -r --cached venv/` 将其移除,并将 `venv/` 添加到 `.gitignore`。随后推送 filter-branch 重写时又重新引入了它,需要进行第二次移除操作。 ## 真实数据,真实结果 在典型的 7 天运行中,AVEN 会处理: - 来自 NVD 的约 1,600–1,800 个 CVE - 来自 CISA 的约 1,600 个 KEV 条目 - 以 2 秒的速率限制安全间隔对所有 CVE 进行 GitHub PoC 搜寻 - 完整的 ExploitDB CSV 交叉引用 - 通过 FIRST.org batch API 获取每个 CVE 的 EPSS 分数 - 跨 10 个模拟企业资产的资产关联 - 为每个 MEDIUM+ CVE 自动生成 Sigma 规则 ![实时 Pipeline 运行](https://static.pigsec.cn/wp-content/uploads/repos/2026/06/097631709b133421.png) 一次实时运行的输出示例: ``` CRITICAL: 0 | HIGH: 2 | MEDIUM: 66 | LOW: 1,730 CVEs: 1,803 | KEV: 1,614 | PoCs Found: 146 | Assets Exposed: 876 ``` 该运行中得分最高的 CVE:CVE-2026-50751 (Check Point Security Gateway) — CVSS 9.3,ACTIVE 成熟度,CISA KEV 已确认,6 个 GitHub PoC 代码库,MITRE T1078 (Valid Accounts)。得分:62.9/100。 ## 技术栈 | 组件 | 技术 | | ------------- | -------------------------------- | | 语言 | Python 3.10+ | | 数据库 | SQLite (通过标准库 sqlite3) | | API 后端 | FastAPI + Uvicorn | | 前端 | 原生 HTML/CSS/JS | | 调度 | schedule 库 | | CVE 数据 | NVD REST API v2 | | KEV 数据 | CISA JSON 订阅源 | | 漏洞情报 | GitHub Search API + ExploitDB CSV| | EPSS 数据 | FIRST.org API | | 警报 | Slack Incoming Webhooks | ## 路线图 - [ ] 基于 CPE 的资产匹配,以实现更高精度的关联 - [ ] 将 Metasploit 模块检测作为成熟度信号 - [ ] 通过 SMTP 发送电子邮件警报通道 - [ ] 使用 compose 文件进行 Docker 部署 - [ ] 历史趋势跟踪——运行间的分数变化差异 - [ ] 为已验证的 CVE 自动生成 Nuclei 模板 ## 关于作者 由 Fernando Cortez 构建的安全工程毕业设计作品集项目。目标职位为 Security Engineer,专注于漏洞情报、检测工程和安全自动化。 [GitHub](https://github.com/cpt-ferna02)
标签:GPT, Python, 威胁情报, 安全, 开发者工具, 无后门, 漏洞管理, 网络调试, 自动化, 超时处理, 逆向工具