太懂这种需求了！市面上大部分SCA工具都把CVE漏洞当唯一KPI，完全不管依赖库在实际使用中可能遇到的功能性bug，还有那些看起来安全但早就没人维护的“僵尸库”，踩过坑的人都懂有多闹心。给你推荐几个真正侧重依赖健康和缺陷追踪的工具，完全匹配你的需求：

• Snyk
  虽然它常被当作安全工具，但现在的依赖健康模块做得相当到位：

  • 能深度扫描你的依赖树，针对每个依赖的当前使用版本，抓取对应代码仓库里标记为bug的开放issue，生成聚合统计列表；
  • 会从多个维度评估维护状态：比如过去3个月的bug修复速度、代码提交活跃度、版本发布频率，甚至能识别出“长期未修复bug堆积”的库；
  • 明确区分功能风险和安全风险，不会把两者混为一谈，帮你优先处理那些影响业务功能的问题。

• Dependabot
  作为代码仓库原生的依赖管理工具，它不止能提醒安全更新：

  • 自带的依赖健康面板会展示每个依赖的开放bug类issue数量（自动过滤仓库里的bug标签），还能关联到具体的issue详情；
  • 会跟踪库的长期维护状态：比如最近6个月有没有新版本发布、贡献者数量是否稳定，直接标记出“僵尸库”（超过1年无更新且开放bug堆积）；
  • 可以自定义规则，比如当某个依赖的开放bug超过X个时，自动触发提醒，提前防控功能风险。

• Depfu
  这个工具完全聚焦于依赖的整体健康，安全只是附加项：

  • 扫描依赖树后，会针对每个依赖的使用版本，拉取仓库上所有开放的功能性bug，整理成清晰的列表，还会统计bug的类型（比如性能问题、功能异常）；
  • 生成的健康评分基于三个核心维度：bug修复周期、未解决bug占总issue的比例、项目的活跃贡献者数量，直接告诉你某个库是不是“太buggy”；
  • 支持集成到CI/CD流程里，每次代码提交时自动检查依赖的功能风险，不用手动跑扫描。

• OSS Review Toolkit (ORT)
  这是个开源工具集，其中的Advisor模块专门做依赖健康分析：

  • 能对接代码仓库的issue数据，针对依赖的指定版本，过滤出功能性bug并生成聚合统计；
  • 会计算多个维护健康指标：比如bug关闭率（过去半年已修复bug/总开放bug）、平均bug修复时间、最近的代码提交频率，帮你判断库的维护是否到位；
  • 完全可自定义规则，比如你可以设置“开放bug超过20个且过去3个月无修复”就算高功能风险，工具会自动标记这类依赖。

最后给个小建议：如果你的项目托管在主流代码仓库平台上，优先考虑Dependabot或Snyk，因为它们能直接对接平台原生数据，统计的bug和维护状态会更准确；如果需要高度自定义规则，ORT会是个不错的选择。