osv-scanner 的安装与使用：用机器找出依赖包里的 CVE

适用对象：想检查自己的应用或服务的依赖包里有没有混入已知漏洞（CVE）的人。尤其适合「靠 AI 帮忙做出来了，但依赖的安全性全凭摸索」的人。这里完全不涉及攻击手法。只讲检查自己脚下（自己的锁文件）的防御。

1. osv-scanner 是什么

它是 Google 用 Go 语言开发的开源漏洞扫描器。漏洞数据用的是跨语言的开放漏洞数据库 OSV.dev。它不只能读 npm，还能横跨 PyPI（Python）、Go、Rust、Maven（Java）等众多生态的锁文件——这正是它与 npm audit 这类语言专属工具最大的区别。

原理很简单。把锁文件里写明的「实际解析出的版本」列出来，再用每个包＋版本去比对 OSV 的数据，返回对应的 CVE 与修复版本。它看的是锁文件，而不是清单（package.json 里 ^ 写法＝下限），这一点很重要，也与 以实际运行版本来判定的原则 一致。

2. 安装

可以按操作系统或喜好挑选安装方式。下面这些都是官方提供的。

如果不想常驻任何东西、只想在 CI 里用，也可以不安装、直接用 Docker 镜像运行。

# 确认装好没
osv-scanner --version

3. 运行

基本就两种：「把整个目录递归扫描」或「点名某个锁文件」。

# 递归扫描整个项目（自动检测锁文件）
osv-scanner scan -r ./
 
# 点名锁文件（npm / pnpm / yarn 等）
osv-scanner scan -L pnpm-lock.yaml
 
# 以 JSON 输出结果（交给 CI 或别的工具时）
osv-scanner scan -L package-lock.json --format json
 
# 连容器镜像一起检查
osv-scanner scan image my-app:latest

用 Docker 镜像（无需安装）运行的例子：

docker run --rm -v "$(pwd):/src" ghcr.io/google/osv-scanner:latest scan -r /src

怎么读输出

如果命中，会以表格列出包名、当前版本、CVE/Advisory ID、修复版本。要做的只有一件事——升到修复版本以上、更新锁文件、再跑一次确认它已经消失。如果想细看某个 CVE 编号的内容（严重度或被利用情况），把编号粘到 CVE/KEV 查询，一屏就能确认 CVSS 以及是否处于被利用状态（KEV）。

4. 让它持续运行（集成进 CI / cron）

手动跑一次就完事，是没有意义的。只有在每次构建前、或每天的 cron 里自动执行，才真正起作用。osv-scanner 找到漏洞时会返回非 0 的退出码，所以把它直接放进 CI 的步骤里，就能在危险依赖混入时让构建中止。

5. 与其他工具的取舍

别「先上 osv-scanner 再说」，而要在自己的架构里挑最顺手的那个才对。

总之，osv-scanner、pnpm audit、Dependabot 不是竞争关系，而是分工不同。需要跨多语言且不依赖 GitHub 就用 osv-scanner，单一 npm 用自带 audit，以 GitHub 为中心就用 Dependabot——叠着用也无妨。重要的是「一定要有某一个在自动持续运行」。面对经由供应链的混入（像 Codecov 事件 或 xz-utils 后门 那样），对依赖的持续检查就是第一道防线。

本站自己是怎么做的

本站对依赖的自我审计，是把 pnpm audit 放在每次部署前必跑＋每日 cron（一旦出现 high/critical 就中止构建并发邮件通知）。没选 osv-scanner，是因为本站采用不在 GitHub 放仓库的架构、依赖也是 npm 单一——「免费、无需额外二进制、不依赖 GitHub」这些条件，pnpm audit 都满足。这是把 文章里写的标准 套用到自己身上的结果，也成了产品的说服力。另外，如果只是想不安装、马上在本机试一次，本站也准备了在浏览器内即可完成的 依赖包漏洞扫描器（只需粘贴锁文件、不上传）。

接着读

• 按技术：Next.js 的 CVE 应对（以实际运行版本判定、机器监控）
• 术语：CVE ／ CVSS
• 事故：Codecov — 供应链污染
• 工具：依赖漏洞扫描器（浏览器内完成） ／ CVE/KEV 查询