DependencyTrack/dependency-track

如果你已经在产出 SBOM、或愿意开始产出，并且需要一个地方看清某个漏洞同时影响哪些项目，Dependency-Track 值得考虑。它是需要自建的服务端平台，不是即插即用的扫描器，采用前要准备好托管、数据接入和版本迁移。

解决什么问题

团队想知道某个第三方库新披露的漏洞是否影响自己发布的任何东西。常见做法是对每个仓库、每种语言分别跑扫描器、看各自的报告，答案取决于你有没有记住所有项目存在、有没有逐个重跑。换成 Dependency-Track 后，输入单位变了：每个应用发布一份软件物料清单（SBOM），平台持续把这份组件清单与漏洞情报做关联。得到的不是单项目报告，而是组合视图——哪些组件有漏洞、哪些应用在用它们。

有什么不同

Dependency-Track 以 SBOM 作为主要数据来源，这是它最关键的设计取舍。它不靠自己解析源码或二进制，而是接收组件清单（项目主题和 README 围绕 CycloneDX、package URL，以及 NVD、OSS Index 一类漏洞数据源），并监控组合内每个应用所有版本中的组件使用情况。这让它能回答单项目扫描难以回答的问题：哪些项目用了某个组件、哪些版本受影响。

平台采用 API 优先设计，这让 CI/CD 集成比较实际：构建过程可以自动上传 SBOM。代价是架构上的承诺：你必须能为应用生成 SBOM，而且平台价值取决于这份清单是否及时更新。它还是集中式服务，带数据库和漏洞数据同步，等于给供应链多加了一个运维组件。README 提示 v5 是当前主线、v4 处于维护模式并将在 2026 年 12 月停止支持，所以选哪个版本、如何迁移本身就是决策的一部分。

谁值得试

适合拥有多个应用、设有安全或平台团队，并且已有或计划建立 SBOM 流水线的组织，比如构建时产出 CycloneDX 文档的团队。组合视图和 API 优先设计，适合希望把持续监控接进 CI/CD、而不是做一次性扫描的团队。

不适合只想检查单个项目依赖的个人开发者或小团队：本地扫描器路径更短，专门搭一套服务并维护 SBOM 生成并不划算。无法产出 SBOM 的团队也不适合，因为这正是平台设计所依赖的输入。如果你已经使用 v4，升级到 v5 有单独的迁移文档，且 v4 支持将于 2026 年 12 月结束。

使用条件与边界

实际前提有三：能运行服务端的机器、要追踪应用的 SBOM、以及与漏洞数据源的连通。README 指向用 Docker Compose 的快速上手教程启动本地实例，项目还提供面向 Kubernetes 的 Helm chart，Docker Hub 上有 API 服务端镜像。前端在独立仓库，用户文档也在专门的文档仓库，因此安装期间要查阅多个来源。

长期维护成本更高。系统的价值取决于流入的 SBOM，因此需要把 SBOM 生成固化到构建流程中；漏洞数据源和平台本身也要定期同步、升级。若你目前在 v4，v4 到 v5 的迁移指南是该切换前的必读材料。提供的 README 摘录没有说明硬件规格、数据库选型或扫描深度，这些要按自身规模对照完整文档确认。

HotRepo 点评

HotRepo 记录的历史很薄：该仓库只在 2026-10-27 上过一次每日趋势榜，当天 4,357 星、+7。单次有日期的观察无法判断关注度是在上升还是下降，这个样本也不足以判断热度能否持续。2023-10-27 的 Hacker News 帖只有 3 分、1 条评论，而那条评论基本复述了项目自己的介绍，没有提供独立评价。考虑到项目创建于 2013 年、属于 OWASP 项目，采用前更值得确认的是它对你所用构建系统的 SBOM 接入方式，以及 v5 迁移的当前状态，而不是星数趋势。