按提交哈希查依赖漏洞和按包版本查，两种口径差在哪

按提交哈希查依赖漏洞和按包版本查，两种口径的差别不在速度，而在覆盖范围。版本口径只能命中「官方发布过版本并被写进公告区间」的缺陷；哈希口径能追到具体提交，把没正式发过版本的自行维护分支、私有仓库和被回滚的修复都纳入判断。公开漏洞数据服务本身同时提供这两种查询入口，说明它们被设计成互补而非二选一。

版本口径命中什么

版本口径的输入是「导入路径加版本号」，查询结果依赖公告把受影响范围写成可比较的版本区间。它的优点是确定性强：锁定文件里记录什么版本，就按什么版本判定，不需要额外构建信息。

它的三个盲区：

• 用了上游未发布的提交，版本号仍是上一个正式发布版，判定会落在旧区间里；
• 自行打补丁把缺陷修掉了，版本口径仍然报命中，形成误报；
• 私有分支或内部复刻的模块没有版本谱系，压根查不到。

哈希口径补的是哪一段

哈希口径的输入是一次构建实际使用的提交标识，判定依据是「引入缺陷的那次提交」与「修复它的那次提交」在历史中的位置。因此它能回答版本口径回答不了的问题：这个二进制里到底有没有那段代码。

代价是要求构建过程可追溯。以 GoLang 生态为例，构建时应把各依赖模块的实际版本与对应提交标识一起记录下来；一旦产物里没有这些信息，哈希口径就无从查起，只能退回版本口径。

实操上两者怎么配合

先按版本口径做例行扫描，成本低、可批量；出现命中再按哈希口径复核一次，把「版本说有问题」和「代码真的在里面」区分开。走完这两步，排期依据才站得住。

框架层也要纳入清单。内容管理系统这类项目除了语言运行时，还有负责数据映射的框架层组件，它们同样是间接依赖，只在业务模块里查版本会漏掉这一层。

容器化部署要补的记录

部署方式如果是容器镜像，查询时最容易断的一环是「线上正在跑的镜像对应哪次构建」。把镜像标识、构建时间与依赖清单写进同一次发布的记录里，事故时才不用靠翻日志重建对应关系。用面板或镜像方式部署的站点，默认监听端口一类的运行参数也应与这份记录放在一起，避免排查时反复确认环境。

常见问题

只有一种口径可以吗？ 可以，但要接受它的盲区。只用版本口径时，凡是自行打补丁或未发布提交的场景都无法自证清白。

哈希口径会不会漏掉只有版本表达的公告？ 会。部分公告只提供版本区间，没有对应提交信息，这类条目仍需版本口径判定。

构建元数据该保留多久？ 至少覆盖当前在线版本与可回滚的历史版本区间，回滚一次就要能查一次。