每小时扫描GitHub依赖中的恶意包并推送Slack告警

原文要点

原模板定位为每小时跑一次：拉取GitHub Advisory Database最近7天恶意包与严重公告，枚举组织或用户仓库并下载依赖图SBOM，按受影响版本范围精确比对，已报告项用首次运行创建的n8n Data Table去重。仅对新事件调用Gemini生成处置建议，发Slack、入表，且只在私有仓库开issue；无锁定版本只按影响全版本公告提示并标未确认。作者提醒公告库可能滞后数小时。

这次做成什么

在自有n8n 2.x里搭一个隔离测试版供应链告警流：定时触发→拉公告→枚举测试仓库→比对依赖版本→去重分支→仅命中时生成建议→Slack/表/issue输出。本站练习用合成公告与两个假仓库验证字段映射，不导入真实生产凭据。

准备什么

• n8n 2.x可用实例且允许使用内置Data Tables
• GitHub测试组织或账号，经典PAT带repo，或细粒度PAT带Contents read与Metadata read
• 如需自动开issue，GitHub凭据额外带Issues write且只用私有测试仓库
• Google AI Studio的Gemini API key，先确认可用模型与配额
• Slack测试工作区与频道，例如#sec-lab，不使用真实告警频道
• 每个测试仓库Settings的Code security里已启用dependency graph

具体怎么做

1. 导入模板并先做隔离

   在n8n.io/workflows/20529页面复制或导入原模板到一个新建测试实例；不要下载所谓本站JSON，本站不复刻原工作流文件。先关闭发布，仅用手动Execute workflow。

2. 配置Settings与凭据

   打开Settings节点：github_owner填测试组织名，owner_type填org；lookback_days首次设30，include_critical_vulnerabilities先设true，create_github_issues设false，repo_name_filter填supply-lab，max_repositories设5。把Fetch Advisories、List Repositories、Get Dependency Graph、Create GitHub Issue都选同一个GitHub测试PAT。

3. 接Gemini与Slack

   Gemini节点填入Google AI Studio key，保持仅在New incident分支后调用；Slack Supply-Chain Alert连接测试OAuth，频道改成#sec-lab。首次运行让工作流自建Data Table，字段至少含advisory_id、package、repo、reported_at、status。

4. 灌入合成数据跑通分支

   用下面CSV在Fetch Advisories后临时替换为测试数据，另造两个仓库：supply-lab-a的lockfile含lodash 4.17.20，supply-lab-b含4.17.21。执行一次，应只看到a命中进入Gemini/Slack，b跳过；再执行一次，同advisory应被Data Table跳过。

5. 发布后观察

   确认无误再发布为每小时触发。第一周每天核对Data Table新增行、Slack消息数和GitHub私有issue数；把create_github_issues改true前，必须确认目标仓库全为私有测试仓库。

可直接复制的材料

{"github_owner":"example-org-lab","owner_type":"org","lookback_days":30,"include_critical_vulnerabilities":true,"create_github_issues":false,"repo_name_filter":"supply-lab","max_repositories":5,"slack_channel":"#sec-lab","data_table":"supply_chain_reported_incidents"}

你是供应链安全值班助手。输入会给出一个GitHub公告、受影响包名、版本范围、命中仓库、依赖来源manifest或lockfile、是否私有仓库。只基于输入输出中文Slack告警，分四段：1发生了什么，用一句说明包名、公告ID、严重性或恶意标记；2为什么命中，列出本仓库当前版本与受影响范围的比较结果；3现在做什么，给出升级、回滚、暂停发布、轮换密钥、检查lockfile与CI缓存的顺序；4如何排查是否被入侵，列出要看的构建日志、发布记录、网络出站、npm或PyPI安装时间。不要编造CVE、链接、日期或已完成的处置动作；若版本无锁定且公告并非影响全版本，结尾写未确认需人工补lockfile。

advisory_id,package,ecosystem,type,severity,affected_range,published_at
GHSA-LAB-0001,lodash,npm,malware,critical,<4.17.21,2026-10-06T00:00:00Z
GHSA-LAB-0002,requests,PyPI,vulnerability,high,>=2.0.0,<2.32.4,2026-10-05T00:00:00Z
repo,manifest,package,version,private
supply-lab-a,package-lock.json,lodash,4.17.20,true
supply-lab-b,package-lock.json,lodash,4.17.21,true
supply-lab-c,package.json,lodash,,false

输入与输出示例

本站虚构演示，未调用真实GitHub/Gemini/Slack，数字与字段仅为核对逻辑。

输入

合成公告GHSA-LAB-0001影响npm包lodash版本<4.17.21；supply-lab-a锁定4.17.20，supply-lab-b锁定4.17.21，supply-lab-c只有package.json无锁定版本。

对应输出

首次执行只有supply-lab-a进入新事件分支，Slack收到：命中GHSA-LAB-0001，lodash 4.17.20落在<4.17.21内；建议先升级到4.17.21以上、暂停发布、检查最近安装时间与CI缓存。Data Table新增一行advisory_id=GHSA-LAB-0001,repo=supply-lab-a；supply-lab-b因版本不落入范围跳过，supply-lab-c因公告非全版本且无lockfile只记未确认不告警；第二次执行同公告被去重。

做完检查这些

• Settings里owner_type与github_owner匹配，否则仓库列表为空
• GitHub凭据在四個节点都选中且权限包含依赖图读取所需范围
• Data Table首次运行后存在并能按advisory_id加repo去重
• lodash 4.17.20命中而4.17.21不命中，说明版本范围比较生效
• Gemini只在有新incident的分支后调用，空跑小时不产生AI调用
• create_github_issues为true时仅在私有测试仓库生成issue

容易卡住的地方

• 公共仓库默认开依赖图，私有或旧仓库要逐个到Code security确认
• 细粒度PAT少给Metadata read会导致List Repositories失败
• 无lockfile的manifest不能当成精确命中，只能标记未确认
• GitHub Advisory Database可能滞后攻击数小时，本流不能替代lockfile与发布冷却
• 把测试频道指到真实#security-alerts会造成误报骚扰
• 原模板界面与表达式未由本站实测，导入后需逐节点核对