Aeon漏洞扫描实战：自主智能体如何在100多个开源仓库发现高危漏洞并私有披露
Aeon漏洞扫描实战：自主智能体如何在100多个开源仓库发现高危漏洞并私有披露
Aeon 是一个运行在 GitHub Actions 上的自主 AI 智能体框架，其内置的 vuln-scanner 技能可以每周无人值守地扫描热门开源仓库：先用 Semgrep、TruffleHog、osv-scanner 等专业扫描器加代理式代码审计找出真实可利用的高危漏洞，再按"依赖 CVE 走公开 PR、代码漏洞走私有披露"的原则安全地交给维护者。截至目前，这套闭环已覆盖 100 多个开源仓库、约 470 万 stars。
目标选择：如何自动挑选值得扫描的开源仓库
vuln-scanner 不需要你指定仓库，它可以自动从 github-trending 技能 的链式输出中挑选目标，筛选规则非常克制（见 skills/vuln-scanner/SKILL.md 的 A1 步骤）：
- 优先选择能推理的语言：JS/TS、Python、Go、Rust、Solidity；
- ≥50 stars、非 fork、近 6 个月活跃，且处理不受信任输入（鉴权、加解密、网络、文件 IO）；
- 跳过 CTF/教学型故意漏洞仓库（DVWA、juice-shop、*ctf 等）；
- 30 天内扫过的仓库自动去重（状态记录在
memory/vuln-scanned.json）； - 没有 PVR 也没有 SECURITY.md 的仓库直接跳过代码审计——因为"没有安全渠道 = 不做任何公开动作"。
你也可以在 var 里直接指定 owner/repo 定点扫描某个项目。
四层扫描器 + 代理式逻辑审计：比 grep 更可靠的发现方式
纯 grep 的误报率太高，Aeon 的做法是"工具扫描 + 模型推理"互补：
| 扫描层 | 工具 | 擅长发现 |
|---|---|---|
| SAST 静态分析 | Semgrep（security-audit / owasp-top-ten / secrets 规则） | 注入、鉴权缺陷、危险 API |
| 密钥泄漏 | TruffleHog --only-verified（文件系统 + git 历史两遍） |
经过真实验证的密钥，不是模式猜测 |
| 依赖 CVE | osv-scanner | 已公开的供应链漏洞 |
| 智能合约 | Slither（有 Solidity 时才启用） | 合约逻辑缺陷 |
| 动态模糊 | 仓库自带的 cargo-fuzz harness（有限时长） |
特定畸形输入才触发的崩溃 |
更关键的是 A3.6 的代理式逻辑审计：SAST 和 fuzz 都看不到"授权绕过、业务逻辑、多步信任边界"这类漏洞，而 Aeon 智能体自己就是扫描器——先建立威胁模型，枚举所有不可信输入入口点，按暴露面排名，对 top-N 入口做 source-to-sink 追踪，产出候选漏洞列表。
每个工具的成功/失败状态都会被如实记录（空输出 ≠ 干净，全部工具失败 = 报错而不是"审计通过"）。
人工级分诊与 PoC 验证闸门：高危漏洞必须先复现
扫描器命中只是候选，不是漏洞。每条发现都要过两道关：
- 人工级分诊（A4）：打开报告行读取上下文 30–50 行代码，用一句话写出"攻击者控制什么、能达成什么"，写不出来就丢弃；还要确认该函数在生产路径上可被外部输入到达。测试目录、示例代码、需要更高权限的攻击直接排除。
- PoC 验证闸门（A4.5）：任何 HIGH/CRITICAL 的代码漏洞声明，必须通过 scripts/vuln-poc-gate.sh 可执行复现——智能合约在钉住真实区块的链上 fork 里跑 Foundry 测试断言被禁止的结果，其他语言跑确定性本地验证脚本，且结论与审计 commit 绑定哈希。复现失败不能降标绕过，只能标记
needs-verification留给人工。
这套机制保证"模型说高危"不等于"发布高危"，是整个项目敢于自主运行的底气。
披露路由实战：依赖 CVE 走公开 PR，代码漏洞走私有披露
这是 vuln-scanner 最见功力的部分——把每条发现路由到正确的披露渠道（A5 步骤）：
| 发现类型 | 披露渠道 | 原因 |
|---|---|---|
| 依赖 CVE（已公开） | 公开 PR 升级依赖版本 | CVE 已是公开信息，补丁 PR 是净收益 |
| 代码漏洞 / 已验证密钥 / 合约缺陷 | PVR 私有漏洞报告（/reports API） |
公开即制造零日，必须私下给维护者 |
| 依赖库内的 fuzz 崩溃 | 向依赖库提公开修复 PR | DoS-only、无利用链需要保密 |
| 无 PVR 且无 SECURITY.md | 暂存草稿 + 列入观察清单 | 没有安全渠道就不公开，绝不做"备份渠道" |
几个值得注意的细节：
- SECURITY.md 优先：很多大厂组织级策略指定了专属漏洞门户（如 PSIRT/邮件），Aeon 会先读仓库自己的安全策略并遵守，而不是想当然用 PVR；
- 观察清单自动回捞：没有渠道的发现会存入 memory/security-watchlist.md 格式的清单，
resubmit模式每周探测 PVR 是否被启用，一旦翻转就自动补交积压的 advisory； - 私有邮件兜底且 fail-closed：只有 PVR 和文档渠道都不存在时，才会准备给维护者的私有邮件草稿；自动发送受一整套闸门保护——每日 1 封上限、同收件人 7 天冷却、MX 域名可达性检查、正文密钥嗅丝、可随时拉闸的 kill-switch，任何一项不满足就不发。
追踪闭环：vuln-tracker 让每条披露都有下文
提交披露不是终点。skills/vuln-tracker/SKILL.md 定义的追踪技能每天轮询一次 vuln-scanner 的所有产出：
- PR 生命周期：维护者有没有评论、请求修改、PR 是否合并/关闭；
- PVR 分诊状态：
triage → draft（维护者接受）→ published（正式公告），30 天无响应自动升级提醒； - 披露队列老化：CRITICAL 超 3 天、HIGH 超 7 天、MED/LOW 超 14 天未发出即告警。
所有状态汇入一块按 stars 排名的 "Stars Secured" 仪表板（memory/topics/vuln-followup.md），运营者一眼就能看到"哪些仓库已受保护、哪些需要人工介入"。
战绩：100+ 仓库、470 万 stars 受保护
如上图所示，Aeon 的漏洞扫描 + 依赖修复闭环累计为 100 多个开源仓库 落地了安全修复，受保护的仓库合计约 470 万 stars——这些通常是日活用户量很大的基础设施项目。对社区而言，这意味着一批高危问题在被打成零日之前，就已经以负责任的方式流向了维护者。
三步开启你自己的 Aeon 漏洞扫描
- 获取 Aeon 模板并初始化一个实例：
git clone https://gitcode.com/gh_mirrors/aeon12/aeon
cd aeon && ./aeon init
vuln-scanner: { enabled: true, schedule: "0 16 * * 6" } # 每周六扫描+披露
vuln-tracker: { enabled: true, schedule: "30 16 * * *" } # 每天追踪披露进展
- 配置密钥：GitHub token（
GH_TOKEN/GH_GLOBAL）即可跑扫描与 PVR 提交；想让智能体自动发送兜底私有邮件，再配置RESEND_API_KEY、RESEND_FROM等变量。智能合约深度审计可另开 sc-audit 技能（Slither + 不变量推理 + Echidna 模糊测试）。
整个流程不需要本地机器常开，扫描、复现、披露、追踪全部在 GitHub Actions 上无人值守完成，结果通过 Telegram/通知通道同步给你。
小结
Aeon 把"负责任的漏洞披露"拆成了可工程化的闭环：自动选目标 → 专业工具+模型双通道发现 → 人工级分诊与强制 PoC 复现 → 按渠道路由私有/公开披露 → 每日追踪直至关闭。它证明了自主智能体不仅能写代码，也能以"少伤害（do no harm）"为第一原则，安全地参与开源生态的安全建设。想深入了解各步骤的设计细节，可以直接阅读 skills/vuln-scanner/SKILL.md 与 docs/CORE.md 中的安全章节。