GitHub把这漏洞数据藏了3年，开发者写了个监控器24小时抓包

Log4Shell爆发那晚，很多工程师是在凌晨3点被叫醒的。不是因为监控系统报警，而是因为生产环境已经炸了。从漏洞公开到大规模利用，中间往往只有几小时窗口——商业扫描器有滞后，NVD（美国国家漏洞数据库）和GitHub Advisory Database的更新节奏完全不同步。一个做安全基建的工程师算了笔账：同时监控4个数据源，能比单一渠道提前平均6-12小时发现高危漏洞。

这不是理论推演。他写了一个Python监控器，把GitHub GraphQL接口、NVD REST API、OSV（开源漏洞数据库）和厂商安全公告页串成一条流水线。代码开源后，被一家金融科技公司拿去跑了两周，抓到一个Python包的RCE漏洞——官方公告还没发邮件，他们的阻断规则已经上线。

为什么单一数据源不够

GitHub Advisory Database的优势是快。一个漏洞被提交到仓库，GraphQL接口几小时内就能查到。但它的覆盖有盲区：很多CVE（通用漏洞披露）编号在NVD已经公开，GitHub却还没录入。反过来，NVD的权威性强，更新节奏却像邮局——批量处理，定时投递。

OSV走的是另一条路。Google发起的这个项目用标准化格式（OSV Schema）聚合多源数据，支持批量查询和精确版本匹配。但它的实时性取决于上游贡献者，有些生态（比如Rust crates）更新很勤，有些则慢半拍。

这位工程师的解法很直接：四个源各取一个切片，用时间窗口去重，再按严重级排序。代码里硬编码了24小时滚动窗口，实际跑下来，GitHub和NVD的重合率大概60%，剩下40%就是信息套利空间。

监控器的核心逻辑不是"谁最全"，而是"谁最快"。

GitHub接口：GraphQL的甜头与苦头

GitHub的REST API对安全公告支持很浅，想要结构化数据得走GraphQL。这个查询语句的构造有讲究：publishedSince参数用UTC时间戳，ecosystem限定为PIP、Maven、npm等具体生态，否则返回的数据量会爆炸。

代码里埋了几个细节。一是分页用first: 50硬截断，理由是"24小时内新增的高危漏洞超过50个，那这天别干活了，先全员应急"。二是vulnerabilities子查询再套一层first: 10，因为有些公告关联的包版本范围极其混乱，曾经有个Advisory拖出来200多个受影响的版本号，直接把响应体撑到超时。

认证用的是Personal Access Token，权限只需要public_repo。但GitHub对GraphQL有速率限制，计算方式是"节点复杂度分"，这个查询单次消耗大概11分，5000分的配额够跑450次左右。对24小时轮询来说绰绰有余，但如果缩到15分钟粒度，就得考虑分页缓存或者多Token轮换了。

NVD的接口设计完全是另一个年代的风格。RESTful，参数拼URL，返回JSON里套着CVSS v3.1评分向量。代码里只取了baseScore，实际生产环境建议把attackVector、privilegesRequired这些字段也存下来——有些漏洞评分9.8，但需要本地权限，实际风险要降档评估。

从数据到决策：监控器不是终点

抓到原始数据只是第一步。这个监控器的输出格式被设计成直接喂给Slack机器人和内部工单系统：包名、漏洞ID、受影响版本、CVSS分数、数据源、原始链接。工程师的意图很明确——减少人工复制粘贴，把响应时间压到分钟级。

有个被验证过的场景：npm生态的lodash原型污染漏洞。GitHub Advisory先出，NVD晚了4小时，OSV又晚了2小时。如果只用NVD，你的依赖扫描流水线会在这6小时内持续放行有问题的版本。而多源监控的价值，就是在时间差里抢出修复窗口。

代码里留了一个TODO注释：把OSV的批量查询接口接进来。OSV支持一次查多个包版本，对大型代码库更友好。但这位工程师暂时没动——他的判断是，实时性优先于吞吐量，先把"知道有漏洞"这一步做到极致，再优化"查全量依赖"的效率。

监控器跑在AWS Lambda上，定时触发，成本每月不到5美元。对比商业漏洞情报服务动辄数千美元的订阅费，这个方案适合有工程能力的中小团队自建。但代价也明显：需要有人维护接口适配（NVD的API版本去年刚升级过一次，字段结构全变），需要自己做去重和优先级排序，需要把告警噪声压到可接受水平。

开源社区有人提了个PR：把监控结果自动转成SBOM（软件物料清单）的补丁建议格式。这位工程师还没合并——他的顾虑是，自动修复的风险太高，监控器应该只做"情报"，不做"决策"。

最后一个被记录的用户反馈来自一家做供应链安全的初创公司。他们用这套代码监控PyPI生态，三个月内提前发现了7个未被广泛报道的高危漏洞，其中两个后来进了CISA的已知利用目录。他们的工程师在Issue里留了一句话："我们没阻止任何攻击，只是比攻击者早到了几小时。"

如果你的依赖列表超过50个包，你现在用的漏洞通知渠道，能覆盖几个数据源？