OSV-Scanner：Google 官方开源的依赖漏洞扫描器，CLI 与 CI 一体化

OSV-Scanner 是 Google 开源（Apache-2.0）的命令行工具，定位一句话：“an officially supported frontend to the OSV database”。它做的事情很聚焦——把你项目里”用了哪些依赖、什么版本”抽出来，和 OSV.dev 这个开源漏洞数据库做匹配，告诉你哪些包命中了已知 CVE。它不是 Snyk、Dependabot 那种带商业后端的 SaaS，而是一个可以离线跑、可以塞进 pre-commit 和 CI 的瘦 CLI。本文基于 google.github.io/osv-scanner 官方文档做一次冷静分析。

一、背景：为什么需要一个”开源数据库前端”

现代应用的依赖数量动辄成百上千，一个 transitive dependency 里藏着一个 CVE，开发者自己根本不知道。过去这类工具分两派：一派是 Snyk/GitHub Dependabot 这种托管 SaaS，靠自己维护的漏洞库赚钱；另一派是 Trivy/Grype 这种自托管扫描器。OSV-Scanner 的位置很特别：它背靠的 OSV.dev 是一个开源、分布式的漏洞数据库，每条 advisory 都来自权威上游（例如 RustSec Advisory Database、GHSA、PySEC），任何人都可以提改进，用 OSV 这个机器可读格式统一描述”哪个版本区间受影响”。官方在文档里强调三点好处：每条 advisory 来源开放权威、社区可改进导致质量高、OSV 格式把受影响版本范围精确映射到开发者的包列表——结果就是”更少、更可执行”的告警。

二、是什么：两步法的扫描器，不是托管平台

按官方文档，OSV-Scanner V2 的核心概念是一个两阶段流水线：

1. Package Extraction（包抽取）：先从你的项目、容器镜像或其他目标里，提取出”用了哪些包、什么版本”。它识别常见的锁文件（package-lock.json、pnpm-lock、poetry.lock、go.mod、Cargo.lock、maven/gradle 等）以及容器镜像里的已安装系统包（如 Alpine 的 /lib/apk/db/installed）。
2. Vulnerability Matching（漏洞匹配）：把抽出的包版本列表拿去和漏洞数据库比对，输出命中项。

它的两种使用形态：

• CLI 工具：在终端或 CI 里直接跑；
• Go 库：go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest，或作为 Go package 集成进自己的工具。

V2 把命令拆成几个子命令：

三、安装与运行：一条命令进 CI

官方提供 SLSA3 合规的 Linux/macOS/Windows 二进制，并附 multiple.intoto.jsonl provenance，可用 slsa-verifier 校验。包管理器覆盖非常全：

brew install osv-scanner          # macOS
winget install Google.OSVScanner  # Windows
scoop install osv-scanner         # Windows
pacman -S osv-scanner             # Arch
apk add osv-scanner               # Alpine
docker pull ghcr.io/google/osv-scanner:latest

典型用法：

# 扫一个锁文件
osv-scanner scan -L package-lock.json --format json

# 扫整个源码目录（递归）
osv-scanner scan -r ./my-project-dir/

# 扫容器镜像
osv-scanner scan image debian:trixie

# 本地起一个 HTML 报告（端口 8000）
osv-scanner scan -L package-lock.json --serve

# 离线模式：先下数据库到本地，再离线匹配
osv-scanner --offline-vulnerabilities --download-offline-databases ./your/dir

它还支持 pre-commit hook（在 .pre-commit-config.yaml 里加 osv-scanner）、许可证合规扫描（--licenses="MIT,Apache-2.0" 对 allowlist 查违规）、输出 JSON/vertical/HTML 多种格式。

四、关键数据与合规属性

五、口径批判：这个工具不告诉你什么

OSV-Scanner 几乎不做”效果对比 benchmark”，但它的工作方式本身有几处必须点破的边界：

1. 它只查”已知漏洞”，不做模糊测试/代码审计：匹配依赖的前提是上游已经把 CVE 写进了 OSV.dev。0day、未上报的漏洞、以及依赖里”没人知道是漏洞”的恶意代码，它一概看不见。把它当成依赖卫生的基础层，不是安全的全部。
2. 告警量取决于上游 advisory 质量，不是它的扫描深度：官方宣传”更少、更可执行”的告警，本质是 OSV 格式精确描述受影响版本区间带来的，不是扫描算法更聪明。如果某个生态（或某条 advisory）上游标注粗糙，你照样会收到误报或漏报。
3. “扫容器镜像”扫的是包管理器数据库里的已装包，不是你 COPY 进去的源码：它读 /lib/apk/db/installed、dpkg 这类系统包清单，不会去反编译你的静态链接二进制，也不查 SBOM 里没列出来的文件。
4. fix 子命令官方自己警告”在不可信项目上有风险”：文档原话——引导式修复可能触发包管理器执行脚本、跟随项目里指定的外部 registry。也就是说自动升级不是无副作用的，跑之前要信任源码和 lockfile。
5. --experimental-call-analysis 等实验性能力按官方 SemVer 承诺，可能在 Minor 版本就被改或删掉，别把 CI 构建锁在实验标志上。
6. 离线模式需要你自己定期更新本地数据库：--offline-vulnerabilities 用的是本地缓存，不更新就等于在查旧漏洞。
7. 它不替代 SCA/SAST 平台：没有依赖图谱可视化、没有业务风险评分、没有与 JIRA 的自动工单流；这些是商业 SCA 的活。

六、优势与局限

优势：

• Google 官方维护 + OSV.dev 开源数据库，不依赖单一厂商的商业漏洞库；
• 零配置 CLI，brew/winget/scoop 一条命令装好，CI 里几十行就能跑；
• SLSA3 + provenance 可校验，供应链工具自身的供应链安全做得很规范；
• 支持离线、容器镜像、锁文件、pre-commit、许可证合规，形态齐全；
• Go 库可嵌入，方便把扫描能力做进自己的平台。

局限：

• 只查已知 CVE，不做动态分析或代码审计；
• 告警质量受上游 advisory 制约，不同生态覆盖不均；
• fix 自动升级有风险，官方都要求你先信任项目；
• 没有商业 SCA 的治理面（工单、风险评分、依赖图谱）；
• V2 仍在快速演进，实验性标志不稳定。

七、适合谁

• 想要一个免费、可离线、能塞进 GitHub Action/GitLab CI 的依赖漏洞扫描第一步；
• 受够了 Snyk 按开发者席位收费、又不想自己维护 Trivy/Grype 规则的小团队；
• 需要 SLSA 合规、供应链可校验的工程团队；
• 想把漏洞扫描嵌进自己 Go 写的内部平台的团队。

如果你的需求是企业级 SCA（依赖图谱、许可证策略治理、合规报告、与 JIRA/Slack 深度联动），OSV-Scanner 是好的底座，但还需要上层治理工具。

参考来源

• OSV-Scanner 官方文档
• OSV-Scanner 安装文档
• OSV-Scanner 使用文档
• OSV.dev 开源漏洞数据库
• GitHub：google/osv-scanner
• Koala 项目库条目：OSV-Scanner | 代码依赖安全漏洞