google/osv.dev 是什么？

osv.dev 是 Google 维护的开源漏洞数据库与分诊服务，本仓库包含其全部后端、索引器、转换器与部署配置。本文基于仓库结构、README 与近期发布记录，分析其架构、运行方式、适用边界与替代方案。

google/osv.dev 可以商用吗？

可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

google/osv.dev 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

google/osv.dev 是用什么编程语言写的？

主要是 Go（依据 GitHub 的语言统计）。

osv.dev 架构与使用分析：Google 开源漏洞数据库的源码解读

Q: google/osv.dev 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

秒懂

它是什么？: osv.dev 是 Google 维护的开源漏洞数据库与分诊服务，本仓库包含其全部后端、索引器、转换器与部署配置。本文基于仓库结构、README 与近期发布记录，分析其架构、运行方式、适用边界与替代方案。
适合谁用？: osv.dev 适合需要统一、开放、可查询的漏洞数据格式的团队，尤其是已经使用或计划使用 OSV Schema 与 osv-scanner 的项目。它不适合只想快速获得一个漏洞扫描结果的中小型团队，因为完整运行这套系统需要 GCP 基础设施、Terraform、Cloud Deploy、Datastore 等组件，维护成本不低。
能商用吗？: 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库最近一次提交在 1 天前。
用什么语言写的？: 主要是 Go（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · google/osv.dev

它解决的问题：漏洞数据碎片化与格式不统一

安全团队面对多个漏洞源，NVD、Alpine、Debian、GitHub Advisory 各有各的格式和更新节奏。osv.dev 的核心思路是把这些来源统一成一种结构化格式，即 OSV Schema，并通过公开 API 和定期数据快照提供服务。这个仓库不是扫描器本身，扫描器在独立的 google/osv-scanner 仓库里。osv.dev 仓库承载的是整个服务后端，包括 API、索引器、worker、数据导入导出，以及部署在 GCP 上的全部配置。它面向的是需要构建或维护漏洞数据管道的平台团队，而不是终端用户。终端用户通常只接触 osv-scanner 或 osv.dev 网站。

架构拆解：从数据源到 API 的完整链路

仓库结构揭示了数据流。`vulnfeeds/` 负责把外部数据源转换成 OSV 格式，比如 `cmd/alpine` 是 Alpine 的转换器，`tools/debian` 是 Debian 的转换器，还有一个主要针对 NVD CVE 的转换逻辑。转换后的数据进入 `gcp/indexer`，这个索引器负责确定版本，也就是把漏洞影响范围对应到具体生态系统的版本。数据最终存储在 Datastore 中，`gcp/datastore/index.yaml` 定义了索引。`go/` 目录里是共享库和多个命令，包括 `cmd/api`（对外提供查询接口）、`cmd/importer`（导入数据）、`cmd/worker`（后台处理任务）、`cmd/exporter`（导出数据快照）、`cmd/recoverer`（恢复流程）、`cmd/relations`（处理漏洞间关系）。`gcp/workers/` 里有 Python 写的 worker，比如 `oss_fuzz_worker`。整个系统通过 `deployment/` 下的 Terraform 和 Cloud Deploy 配置部署到 GCP。

运行方式：不是一条命令能启动的简单服务

README 明确说，这个仓库包含运行 osv.dev 的全部代码，但部署到 GCP 需要大量配置。首先需要初始化子模块，命令是 `git submodule update --init --recursive`。本地构建需要这些子模块。部署涉及 `deployment/` 目录下的 Terraform 文件、Cloud Build 配置和 Cloud Deploy 配置。如果你想在本地运行 API 或 worker，需要自行研究 `go/cmd` 下的各个命令，但 README 没有提供快速启动指南。数据快照可以从 GCS 桶 `gs://osv-vulnerabilities` 下载，但如何导入到本地 Datastore 需要参考文档。实际使用中，大多数用户不会直接运行这个仓库，而是调用公共 API 或使用 osv-scanner。

扫描器的定位：与主仓库分离，但依赖其 API

README 特别提到 osv-scanner，它是一个 Go 工具，扫描依赖并对照 OSV API 检查漏洞。它能扫描各种 lockfile、Debian Docker 容器、SPDX 和 CycloneDB SBOM，以及 Git 仓库。这个工具放在独立仓库，意味着它的发布节奏与 osv.dev 主仓库不同。近期主仓库的发布记录显示 v0.1.3 在 2026 年 4 月更新，v0.1.2 在 2025 年 9 月，v0.1.1 在 2025 年 9 月，但这些都是主仓库的版本，不是扫描器的。扫描器通过 API 与数据库交互，因此它的功能受限于 API 的查询能力。如果你需要离线扫描或本地数据，可能需要考虑数据快照与本地 API 部署。

真正的限制：GCP 绑定与维护成本

这个仓库不是一个轻量级应用。它深度绑定 Google Cloud Platform，包括 Datastore、Cloud Functions、Cloud Build、Cloud Deploy。`gcp/functions` 里的 PyPI 漏洞发布函数被标记为“maintained, but not developed”，说明部分组件已进入维护模式。`gcp/workers/` 里的 Python worker 与 `go/` 里的 Go 服务并存，技术栈混合，增加了理解成本。部署需要 Terraform 和 Cloud Deploy，这意味着如果你没有 GCP 环境，几乎无法完整运行这套系统。对于只想获取漏洞数据的团队，直接使用公共 API 或数据快照更实际，而不是自托管。此外，数据转换器只覆盖部分源，比如 Alpine、Debian、NVD，其他源如 GitHub Advisory 是否直接支持，README 没有明确。

替代方案：社区工具与商业扫描器的差异

README 列出了一些社区工具，它们使用 OSV 数据但采用不同实现。Trivy 是一个独立的漏洞扫描器，它有自己的漏洞数据库和扫描逻辑，不依赖 OSV API，但也能消费 OSV 格式。pip-audit 专注于 Python 依赖，直接查询 PyPI 和 OSV。Dependency-Track 是一个完整的软件成分分析平台，它集成了多种漏洞源，包括 OSV，但提供更全面的项目管理功能。OSS Review Toolkit 用于许可证和合规检查，也整合了漏洞数据。这些工具与 osv.dev 的核心区别在于：osv.dev 是数据提供方，而这些工具是消费方。如果你需要定制漏洞数据管道，osv.dev 是基础；如果你只需要扫描结果，这些工具开箱即用。

许可证与维护现状：Apache-2.0 下的开放但需谨慎

项目采用 Apache-2.0 许可证，允许商用和修改，但需要保留版权声明。仓库没有被归档，最近一次推送在 2026 年 4 月，说明仍在活跃维护。但发布节奏并不快，v0.1.2 到 v0.1.3 间隔了约 7 个月。维护成本主要体现在：需要跟进上游数据源格式变化，比如 NVD 的 CVE 记录变更；需要管理 GCP 基础设施，`deployment/` 下的 Terraform 配置需要随服务演进更新；子模块的存在增加了构建复杂性。如果你 fork 这个仓库，你需要自己处理这些维护工作。社区工具如 Trivy 由商业公司支持，更新更频繁，但数据源依赖 OSV 的 API，如果 OSV 服务中断，它们可能受影响。

编辑结论

osv.dev 适合需要统一、开放、可查询的漏洞数据格式的团队，尤其是已经使用或计划使用 OSV Schema 与 osv-scanner 的项目。它不适合只想快速获得一个漏洞扫描结果的中小型团队，因为完整运行这套系统需要 GCP 基础设施、Terraform、Cloud Deploy、Datastore 等组件，维护成本不低。若你只是想扫描依赖，直接用 osv-scanner 或社区工具如 Trivy、pip-audit 更轻量。若你决定采用，先确认你的数据源接入需求，比如是否要转换 NVD CVE 或 Alpine 数据，并检查 `deployment/` 下的 Terraform 配置是否匹配你的 GCP 环境。在投入前，至少阅读 https://google.github.io/osv.dev 的文档，尤其是数据格式与 API 部分。osv.dev 的价值在于其开放的数据模型和完整的数据管道，而不是一个即插即用的扫描器。

官方来源

社区笔记