🔒 基础设施安全

# AI系统的依赖安全：
当35个软件包一夜清零

从1个critical漏洞到零漏洞的12小时 · 第三方依赖管理实战记录
📅 2026年7月4日 · 总编辑：皆如
一则真实的系统日志：2026年7月3日晚，自动化安全审计系统报告了一个critical漏洞——WhatsApp通信库@whiskeysockets/baileys被标记为"无补丁可用"。12小时后，漏洞归零。这篇文章记录的不是某个大厂的安全团队如何作战，而是一个人+AI Agent的实战过程。

如果你的AI系统跑着Python和Node.js两个生态的软件包，你的攻击面有多大？

答案可能是你不想知道的——一个中等规模的AI基础设施项目，依赖树展开后轻松超过500个软件包，而审计这些包的安全状态，人工几乎不可能完成。

◆ ◆ ◆
一、问题：一个"无补丁"的critical漏洞

7月3日早6:00，自动安全审计cron发现了问题：

⚡ 发现漏洞:
Severity: critical
No fix available
node_modules/@whiskeysockets/baileys

@whiskeysockets/baileys 是一个开源的WhatsApp Web协议实现，被广泛用于构建WhatsApp Bot和消息桥接服务。这次发现的critical漏洞来自其协议层实现，且官方标注"no fix available"——这意味着截止到检测时间点，上游尚未发布修复版本。

同时，系统还报告了12个系统级安全更新待安装，涉及ncurses、vim、nghttp2、libvnc等多个基础库。

📦 Python生态
0 漏洞
hermes-agent 核心生产环境安全
📦 Node.js生态
1 critical（baileys）
hermes-agent + web 零漏洞
🐧 系统包
12个安全更新待装
ncurses/vim/nghttp2/libvnc
🔍 发现方式
自动化cron每早6:00
pip/npm audit + apt扫描
◆ ◆ ◆
二、修复：不是"等补丁"，是主动升级

面对"无补丁可用"的标记，有两种策略：

- 被动等待——等上游发布新版本，期间承担风险
- 主动检查——确认审计报告的时间点是否已落后于现实

实际排查结果出人意料：上游已经在6小时内发布了新版。从7.0.0-rc.9升级到7.0.0-rc13，恰好覆盖了该漏洞。不是"无补丁"，而是补丁在审计报告生成之后才发布。

操作 | 结果
--- | ---
检查当前版本 | rc.9（含漏洞）
查询npm最新版 | rc13（已修复）
执行升级 | 2个包更新，耗时1秒
安全审计验证 | 0 vulnerabilities

同时，12个系统安全包也全部通过`apt upgrade`完成安装，从ncurses到vim到nghttp2，全量更新。

◆ ◆ ◆
三、验证：单副本排查

修复完成后，一个关键问题是：这个修复是真实的，还是只在某个虚拟环境下有效？系统会不会存在多份依赖，导致实际运行时仍然加载了旧版本？

排查过程涉及四个维度：

检查项 | 结果
--- | ---
全系统扫描包副本 | 仅1份，无重复安装
symlink检测 | 非软链，是真实文件目录
版本一致性 | 实际文件rc13 = package-lock.json rc13
Docker隔离检查 | 无独立容器运行该服务

依赖安全的陷阱往往不是"有没有漏洞"，
而是"你修的是哪一份依赖，
运行的是哪一份"。
◆ ◆ ◆
四、系统化安全审计架构

这次快速响应的背后，是一套自动化的依赖安全审计系统在工作：

📅 每日06:00 — 自动安全审计
├─ 扫描Python依赖 → pip-audit
├─ 扫描Node.js依赖 → npm audit （4个项目）
├─ 扫描系统包 → apt list --upgradable
└─ 发现漏洞 → 生成结构化报告推送
📅 每15分钟 — 审计日志推送（Loki）
├─ 记录所有Agent操作历史
├─ 可追溯执行链路
└─ 支撑事后复盘

这套架构的核心设计理念：不要把安全审计做成一次性的"大扫除"——依赖关系是动态的，今天没有漏洞不代表明天也没有。CI/CD管道每增一个包、上游每发一次更新，安全态势都在变化。每日自动扫描 + 实时推送，才是可持续的方案。

◆ ◆ ◆
五、给技术团队的三点建议

# | 建议 | 说明
--- | --- | ---
① | 自动化优于人工巡检 | 依赖树展开后动辄数百个包，人工审计不现实。每天定时跑一次全量扫描，比每月一次"安全日"有效得多。
② | "无补丁"可能是过时信息 | 安全审计报告中的"no fix available"只代表检查那一刻的状态。关键包上游更新频繁，6小时内就可能发生逆转。主动检查 + 及时升级比干等更有效。
③ | 验证修复的真实性 | 升级≠修复。确认系统中不存在多份依赖副本、确认实际运行的版本与package-lock一致、确认不是symlink导致"假升级"。这些验证步骤和修复本身一样重要。

◆ ◆ ◆
六、写在最后

这次修复中最有价值的不是那个漏洞本身被堵上了——而是整个流程的透明度：从自动发现、人工研判、主动升级到验证闭环，每一步都可追溯、可复现。

对于一个技术团队来说，真正的安全不是"没有漏洞"，而是对漏洞有系统化的感知和响应能力。知道风险在哪、知道怎么修、修了能确认修好了——这三件事做到，比追求"零漏洞"这个静态目标更有意义。

安全不是一次修复的结果，
而是一个持续迭代的生命周期。
每一个cron的黎明运行，
都是对系统的一次无声体检。