用 n8n 与 Gemini 搭建漏洞日报

每天追漏洞公告，麻烦的不只是信息多，还要判断它和自己的技术栈有没有关系。作者做的「资安战情室」，用 n8n 串起情报采集、Gemini 解读和 Vue 日报展示，目标是一份按技术清单生成的每日剪报。

它最有价值的地方，是把官方事实、AI 说明和人工确认分开。但采集范围有明确限制，适合辅助日常查核，不能拿来证明项目没有漏洞。

先筛情报，再让 AI 帮忙读

项目从 NVD 和 GitHub Advisory 获取信息，由 Gemini 辅助阅读，再把结果写成文件。Vue 仪表板只读取生成好的日报，查看时不调用 Gemini，也不需要数据库。

这个分工让采集、解读和展示可以独立运行。作者选择 Gemini 的理由是 Google AI Studio 提供一定额度的 Free Tier，但原文没有给出具体免费额度、模型名称或每日成本，不能据此认定长期运行一定免费。

筛选规则比模型更值得看：

• NVD 只取配置关键词、最近 30 小时首次公布且有有效 CWE 的记录。CWE 是漏洞弱点的分类，不是风险等级。
• GitHub Advisory 只查 config.json 中 npmPackages 列出的公开 npm 套件，不读取项目依赖清单，也不覆盖间接依赖。
• 每个关键词都有获取和保留上限，AI 分析也有笔数上限，日报可能包含未经 AI 分析的记录。

没有符合条件的数据时，流程会跳过 Gemini，生成零笔日报。这能减少无效调用，但零笔只是本次规则没有筛到记录。

日报没有列出，不代表项目没有漏洞。

产品名称没出现在描述里、CWE 较晚补齐，或者记录超出上限，都可能漏收。原文没有说明这些上限的具体数值。

跑起来不难，配置更新有两条路径

新部署需要 Docker、Docker Compose 和能调用 workflow 指定模型的 Gemini API Key。macOS、Windows 可以使用 Docker Desktop，并允许共享项目目录。

先复制配置文件，再在 .env 的 GEMINI_API_KEY= 后填入金钥：

cp .env.example .env

注意这是本机明文文件，虽然已排除版本控制，仍不能上传或分享。Windows 命令提示字元使用 copy .env.example .env，PowerShell 可直接使用 cp。

执行 docker compose up -d --build 后，项目会依 config.json 生成 workflow，把金钥存入 n8n Credential，并让 Gemini 节点选用它。n8n 和仪表板分别使用本机端口 5678、3030。

先按 Execute workflow，确认 reports/ 中出现 latest.json，以及 YYYY/MM/ 下的 security-daily-YYYY-MM-DD.json、security-daily-YYYY-MM-DD.md，再按 Publish。之后每天台湾时间 07:00、时区 Asia/Taipei 执行，电脑和 Docker 都必须保持运行。

修改 config.json 或 .env 后，用这条命令重新导入配置：

docker compose up -d --force-recreate n8n

注意末尾的服务名 n8n。已启用的排程会保持启用，但界面里直接修改的节点会被覆盖；配置错误可通过 docker compose logs n8n 排查。

已有 n8n 的团队需要走另一条路径：执行 node scripts/prepare-reports.js，预建今年至三年后的年月目录；把宿主机报告目录挂载到 /files/reports，设置 GENERIC_TIMEZONE=Asia/Taipei、TZ=Asia/Taipei，并将 /files/reports 加入 N8N_RESTRICT_FILE_ACCESS_TO，多个路径以分号分隔。Linux 还要确保容器的 UID 1000 有写入权限。

随后运行 node build.js，导入生成的 workflow/security-intel-gemini.json。Gemini 节点手动配置 Header Auth Credential，Name 为 x-goog-api-key。这条路径不会读取项目 .env 中的金钥；以后修改配置需要重新生成、导入，并停用旧 workflow，避免重复执行。

仪表板回答的是先查什么

使用时先看报告日期和最后成功产报时间，再看「今天要做的事」，回到官方来源核对版本、受影响条件和已知利用情况。其他信息归入「例行更新」「知悉即可」，支持按 CVE、CWE、产品等条件筛选，并下载 Markdown、JSON。

P0 到 P3 是查核优先顺序，不等于实际受影响程度。

AI 内容会标注「AI 说明，未经人工确认」。新日报写入后刷新页面即可，只有仪表板程序更新才需要重建容器。页面能打开并不能证明当天产报成功，失败原因仍要看 n8n 执行记录。

Telegram 是可选项，默认 telegramEnabled: false。启用时通过 @BotFather 的 /newbot 获取 Token，填入 TELEGRAM_BOT_TOKEN；私聊先发 /start，群组发 /start@你的Bot帳號，再通过 getUpdates 获取 message.chat.id。群组 ID 是负数，例如 -1001234567890；telegramChatId 要保留双引号。

通知在日报写完后发送，因此通知失败时，报告可能已经生成。查询 getUpdates 的地址含 Token，也不能公开。

局域网访问可设置 DASHBOARD_BIND=192.168.1.10，默认 127.0.0.1 仅允许本机。配置中的 dashboardUrl 必须能被接收通知的设备访问，不能填 localhost。

我的判断

我认同这种文件式日报设计：查阅不重复消耗模型调用，JSON 和 Markdown 也方便留档。把 AI 标注为待确认说明、保留官方查核入口，同样比直接输出风险结论稳妥。

局限在于，技术清单需要人维护，采集窗口和过滤条件还会影响覆盖率。原文没有提供漏报率、AI 准确率或人工耗时对照，所以省时效果仍是经验判断。

对前端和 Node 团队，它更像每日情报入口。与读取锁文件、检查直接和间接依赖的工具相比，两者回答的问题不同：前者提示近期有什么值得查，后者更贴近项目实际安装了什么。不能用这份日报替代依赖检查。

能拿来做什么

• 前端或 Node 团队可以先维护一份公开产品和 npm 套件清单，用日报集中查阅相关公告，不填内部项目名称或机敏信息。
• AI 编程引入新依赖后，把依赖清单检查和日报查核一起做；看到条目时核对实际版本，没有条目时也继续检查间接依赖。
• 接入现有 n8n 时，先验证目录写入、手动产报和日期展示，再启用排程；排查时分别检查采集、产报和通知，避免把通知失败误当成整条流程失败。