“漏洞扫描器”准确概括了 OSV-Scanner 的用途，但要理解它如何工作，还得看扫描过程中的两个步骤：先从待扫描的软件中提取软件包信息，再查找受影响版本或代码提交范围与之吻合的漏洞记录。[1][5] 到 2026 年，许多团队已经有了声称能判断风险的仪表盘，真正缺少的是可靠的核查办法。他们需要把依赖锁定文件（lockfile）、软件物料清单（SBOM）、源码树或容器镜像与已知开源漏洞数据对应起来，并保留每项扫描结果的出处。

理解这项工具，可以从它能查明什么入手。一套完整的应用安全计划还要判断：各类语言中的易受攻击函数能否被调用，漏洞利用路径是否暴露在生产环境中，以及业务上的例外安排是否合理。这些问题超出了 OSV-Scanner 能够全面判断的范围。它首先查清的是：待扫描内容包含哪些软件包、版本、代码提交和软件制品，哪些 OSV 记录与它们匹配？[1][2][5]

图片说明：题图选用 Wikimedia Commons 的真实数据中心机柜照片，有别于生成式安全图像或示意图。照片呼应了 OSV-Scanner 对运维证据的重视：漏洞数据与构建、运行过程中实际使用的软件清单对应起来，才有助于排查问题。[8]

先提取软件包信息，再匹配漏洞

官方使用文档明确列出了这两个步骤：OSV-Scanner 先从项目、容器镜像或其他目标中提取软件包信息，再与已知漏洞数据库匹配。[1] 扫描工作中常见的失误，恰好说明了核实输入的重要性。团队先按严重程度统计漏洞数量，随后才发现，扫描的项目清单（manifest）已经过期，SBOM 缺项，镜像与生产环境使用的版本不同，或解析间接依赖时采用了不同的软件包仓库配置。

OSV-Scanner 的设计要求先看输入是否可靠。源码扫描和镜像扫描所依据的材料各有侧重。受支持制品文档对此有明确说明：扫描源码时，扫描器查找锁定文件和项目清单；扫描容器时，已经安装的软件制品比文件系统中散落的锁定文件更重要。[2] package-lock.json 记录项目预定解析出的依赖，容器层则记录实际装入镜像的内容。两者各有用途，混为一谈容易造成误判。

为此，OSV-Scanner 集成了 OSV-Scalibr 的提取功能，并按类别列明受支持的输入。源码扫描支持 Go、JavaScript、Python、Rust、Ruby、PHP、.NET、Java、Dart、Elixir、Haskell、R 等软件生态中的锁定文件和项目清单。镜像扫描能提取已安装的操作系统软件包，以及 Go 二进制文件、Java uber JAR 包、Node 模块、Python wheel 包等语言制品。[2][6] 这些支持各有适用范围。扫描器从一开始就需要辨明：眼前的软件制品究竟属于哪一类。

OSV 如何记录漏洞，决定了扫描器如何匹配

OSV-Scanner 的匹配方式与 OSV 的数据模型紧密相关。按 OSV 的介绍，它使用 OSV 数据格式（schema）汇集漏洞数据库，来源包括 GitHub Security Advisories、PyPA、RustSec、Global Security Database 等。[5] 公开 API 支持按代码提交哈希或软件包版本查询已知漏洞。[5] OSV 希望帮助开发者识别会造成实际风险的已知第三方依赖漏洞，并借助二分查找和版本分析，尽量准确地记录受影响版本。[5]

有了这些数据，OSV-Scanner 能比通用的 CVE 字符串匹配更精确。OSV 数据格式由 OpenSSF 漏洞披露工作组（Vulnerability Disclosures Working Group）维护，目标是用机器可读的格式记录开源漏洞，并对应到各软件包生态及其受影响范围。[7] 用户据此可以理解一条记录所表达的内容：除漏洞名称外，它还明确指出受影响的软件包、版本区间或代码提交范围。

C/C++ 支持说明了这套办法的用途和局限。C 和 C++ 项目往往缺少统一的软件包管理器记录。对于以 Git 子模块引入或随项目存放的依赖，OSV-Scanner 可以使用 OSV 的提交级漏洞数据；对于直接复制进项目、没有保留 Git 历史的依赖，则可以调用 OSV 的 determineversion API 估算版本。[2] 这些做法照顾到了 C/C++ 项目实际引入依赖的方式。不过，同一份文档也提醒，提交级数据覆盖 OSV 中的大多数 C/C++ 漏洞，结果仍会漏掉部分漏洞。[2] 证据更充分，覆盖范围仍有限。

扫描结果应保留出处

OSV-Scanner 的输出同样重视证据。每个漏洞的报告包含 OSV 链接、严重性评分、所属软件包生态、软件包名称、版本、已修复版本（若有）及软件包来源路径。[3] 扫描容器层时，还可以报告软件包在哪一层引入、层的历史记录及相关命令、基础镜像，以及操作系统或发行版信息。[3] 有了这些字段，团队才能逐项复核扫描结果。

排查会议若从“我们有 47 个高危漏洞”谈起，往往既滞后又含混。问题需要问得更具体：哪个锁定文件、镜像层或 SBOM 中的哪个软件包版本匹配了哪条 OSV 记录，是否已有修复版本？[3] OSV-Scanner 保留了这些对应关系。若报告只剩一个红色数字，丢掉了负责人定位并修复问题所需的来源路径，工具的价值就会大打折扣。

安排排查次序时，调用分析尤其值得关注。它尝试区分软件包存在漏洞与项目会调用易受攻击代码这两件事。启用 --call-analysis=<lang> 后，OSV-Scanner 的表格输出可以把结果分为两类：影响项目所调用代码的漏洞，以及影响项目未调用代码的漏洞。[3] “未调用”还不足以证明安全。可达性分析因编程语言而异，覆盖也有限，还受运行时行为影响。不过，它在确认“依赖树中存在漏洞”之后、判断“漏洞在这里能够被利用”之前，补充了一项重要依据。

成熟的漏洞管理需要逐步查明这些问题。发现存在漏洞，就应着手排查；确认相关代码是否可达，再细化处理顺序。生产环境的暴露情况、补偿性防护措施和漏洞利用手段的成熟度，仍要由人结合安全策略评估。OSV-Scanner 能为这套流程补充证据，后续判断仍需逐项完成。

用配置文件记录可复核的例外

osv-scanner.toml 配置文件容易被忽视，却是 OSV-Scanner 中很实用的一部分。按配置文档，用户可以按 ID 忽略漏洞，并选填到期日和理由。软件包覆盖配置（package overrides）还允许忽略软件包、忽略漏洞、忽略或覆盖许可证信息，并设置有效期。[4] 这些记录让团队在跳过告警时留下可供复核的依据，避免养成遇到告警就随手略过的习惯。

忽略项应当作为安全策略的一部分记录下来。注明理由和到期日，例外安排才便于复核；永久忽略且没有理由的条目，则把待处理的问题藏了起来。OSV-Scanner 留出了记录这些信息的位置，是否认真维护，仍取决于仓库负责人。

GitHub Action 也按用途区分了扫描方式。官方文档中的拉取请求（PR）工作流会比较目标分支与功能分支的扫描结果，报告 PR 引入的新漏洞；完整扫描则可以在推送代码时或按固定计划运行。[9] 两者各司其职：PR 扫描拦截新引入的已知漏洞，定期扫描跟踪依赖引入后漏洞公告的变化。混淆这两项任务，容易让团队高估防护效果。

使用修复建议前，要看清执行风险

OSV-Scanner 的引导式修复（guided remediation）把检测结果用于规划依赖变更。文档将 osv-scanner fix 列为实验性功能：它分析完整的传递依赖图，按能够修复的间接依赖漏洞数量，为直接依赖的升级安排优先级，同时考虑严重程度和依赖深度。对于受支持的软件包生态，它还能修改项目清单或锁定文件。[10] 待处理漏洞很多时，这类辅助有助于团队安排修复工作。

文档也明确提示了使用风险：对不受信任的项目启用引导式修复，会触发软件包管理器操作、执行脚本，或访问项目指定的外部软件包仓库。[1][10] 这条警告关系到工具实际执行什么。读取依赖证据，与运行软件包管理器、改写依赖状态，所需的信任条件各不相同。

实际使用时，可以从开发早期开始频繁运行 OSV-Scanner，及时收集依赖证据。扫描结果足以明确判断时，用 PR 检查拦截新引入的已知漏洞；用定期扫描发现新披露的问题；用配置文件留下可审计的例外记录。在受信任的仓库中使用引导式修复，还要明确代码审查和测试要求，并了解软件包管理器将执行哪些操作。

OSV-Scanner 的设计立足于一个朴素而长久的要求：漏洞扫描要紧扣依赖证据，输出要保留足够的出处，让人和策略引擎有据可依，继续判断如何处理。它为完整的安全计划打下基础。依赖及其出处查清之后，团队才能准确讨论漏洞有多严重、相关代码能否被调用、由谁负责，以及如何修复。

来源

1. OSV-Scanner 文档《Usage》：软件包提取与漏洞匹配方法、扫描子命令、输出选项、离线匹配、许可证扫描，以及引导式修复的风险提示。
2. OSV-Scanner 文档《Supported Artifacts and Manifests》：源码与容器扫描的证据差别、受支持的锁定文件和软件制品、C/C++ 提交扫描、随项目存放的依赖处理，以及 Maven 传递依赖扫描。
3. OSV-Scanner 文档《Output》：报告字段、容器层输出、输出格式、SARIF 细节，以及调用分析结果的输出方式。
4. OSV-Scanner 文档《Configuration》：osv-scanner.toml、忽略的漏洞 ID、理由、到期日，以及软件包覆盖配置。
5. OSV.dev《Open Source Vulnerabilities》及 OSV 介绍：漏洞数据库汇集、OSV 数据格式的使用、按提交哈希或软件包版本查询的 API，以及准确记录受影响版本的目标。
6. Google 安全博客《Announcing OSV-Scanner V2》：OSV-Scalibr 集成、软件包提取支持的扩展、可识别镜像层的容器扫描，以及本地 HTML 输出。
7. OpenSSF《OSV Schema》：OpenSSF 漏洞披露工作组对 OSV 数据格式及参考工具的维护。
8. Wikimedia Commons《Datacenter Server Racks (22370909788).jpg》：Carl Lender 拍摄的真实数据中心机柜照片，题图来源页。
9. OSV-Scanner 文档《GitHub Action》：拉取请求扫描、定期扫描、发布扫描，以及工作流的运行方式。
10. OSV-Scanner 文档《Guided Remediation》：实验性 fix 命令、依赖图分析、优先级排序依据、项目清单与锁定文件的变更，以及受支持的修复策略。