AI 加速 CVE 发现后，漏洞治理会卡在依赖图上

Flox 最近把一个老问题重新摆到台面上：AI 发现漏洞变快以后，企业还能不能靠事后扫描来管理包级 CVE。

这个问题不新，但压力变了。Google 的 Big Sleep 发现过 SQLite 零日漏洞，Microsoft Copilot 被用于发现 20 多个开源 bootloader CVE，DARPA 也在推进 AI Cyber Challenge（AIxCC）。这些案例至少说明一件事：漏洞披露的节奏，正在被 AI 往前推。

我更在意的不是“AI 能不能自动修漏洞”。修复从来不只是打补丁，还包括测试、发布、灰度和回滚。真正会先被放大的，是另一个更土的问题：一个 CVE 出来以后，你能不能快速证明公司哪些环境真的受影响。

AI 发现提速后，重复排查会先变贵

包级 CVE 最麻烦的地方，不是名字难懂，而是传播路径长。

一个 OpenSSL、zlib、glibc、npm 包或 Python 依赖出问题，安全团队要回答的不是“有没有补丁”。更难的是：哪些服务、镜像、开发环境和生产运行时带了它。

很多组织现在靠扫描器补这张账。主机扫一遍，镜像扫一遍，仓库扫一遍，运行环境再扫一遍。CVE 少的时候，这套办法还能忍。CVE 变多以后，重复 triage 会吞掉大量时间。

平台工程和 DevEx 团队会被推到前台。他们要决定环境怎么声明、怎么发布、怎么复用。安全工程和供应链安全负责人则要决定扫描结果能不能转成可审计的证据，而不是一堆每周刷新的告警。

这里的动作很具体：平台团队可能会推迟继续堆扫描器，转而补依赖索引、SBOM 管道和环境版本引用；安全团队也会把“发现某个 CVE”和“证明哪些环境受影响”拆成两件事管理。

这才是 Flox 这篇文章的主线。

同一条安装命令，不等于同一张依赖图

Flox 对 apt、dnf、zypper、pip、npm、cargo 等工具的批评，核心是非确定性。

同一条安装命令，在不同平台、不同时间、不同镜像源、不同缓存状态、不同版本范围下，可能解析出不同依赖。表面看命令一样，实际落到机器上的包未必一样。

这会直接影响 CVE 排查。两个环境如果不能证明等价，就很难把一次分析复用到另一处。安全团队只能反复扫，反复判断，反复解释误报和漏报。

很多团队以为有 lockfile 就够了。这个判断只对了一半。

应用运行时还依赖基础镜像、系统动态库、证书包、编译工具和启动脚本。漏洞常常藏在这些“没人直接声明、但被间接带进来”的传递依赖里。

所以问题不是有没有锁文件，而是锁住了多大范围。只锁应用依赖，不等于锁住运行环境。

Nix/Flox 是压缩分析成本，不是消灭 CVE

Nix 的关键概念是 closure，也就是一个环境的完整传递依赖集合。Flox 基于 Nix，把环境声明、解析结果和版本化共享包装成团队工作流。

在这个模型里，store path、lockfile 和 SBOM 不只是记录。它们可以变成查询、比对和去重的证据。

Flox 提到的 Big O 类比，要谨慎看。它不是严格性能基准，也不是 O(1) 修复承诺。更准确的说法是：传统模式常常要对 n 个环境分别做昂贵分析；Nix/Flox 模式仍要盘点 n 个环境，但可以把真正费力的漏洞适用性判断，压缩到 u 类唯一依赖图上。

举个抽象例子：500 个环境如果对应 50 个唯一 closure，昂贵分析更接近做 50 次，而不是 500 次。这个例子只说明治理思路，不代表实测性能。

这对两类人影响最大。

平台工程与 DevEx 团队要补的是环境工程能力：统一声明入口，减少临时安装，给开发、CI 和生产运行时建立可追踪的版本关系。否则依赖图再漂亮，也只停在局部工具里。

安全工程与供应链安全负责人要补的是证据链：SBOM 怎么生成，扫描结果怎么映射到 closure，哪些依赖图已经分析过，哪些环境需要重新验证。告警数量不是核心，能不能去重和复用判断才是核心。

限制也不能省。

Flox/Nix 只能覆盖被它捕获的依赖。如果服务启动时临时 curl 一个二进制，运行时 pip install 一个包，或者从插件市场拉组件，这些仍然要单独固定和追踪。

修复流程也不会被省掉。测试、灰度、发布协调、生产回滚都还在。Nix/Flox 能改善的是“我到底受不受影响”的证明成本，不是替团队承担上线风险。

接下来要看的变量很清楚：大型团队会不会把“依赖图可证明”列为平台工程指标。

如果答案是否定的，AI 发现漏洞越快，很多组织越会被拖回老问题：账本不清，扫描再勤也只是补窟窿。