Trivy 扫 slim 基础镜像时 OS 层 CVE 泛滥而语言层依赖漏报，怎么统一卡点？

背景：我做了 3 年安全加固，最近给一套 Spring Boot 3.1 服务做镜像安全加固，基础镜像从 openjdk:8-jdk 换成了 eclipse-temurin:17-jre（slim 倾向，单镜像约 480MB），K8s 1.28 + containerd 1.7，私有 Harbor 单节点。CI 里用 Trivy 0.48 做发布卡点，命令是 trivy image --severity CRITICAL,HIGH --exit-code 1 registry.local/app:tag。

现象：卡点上线三个月后出现两个让我很纠结的现象：

1. OS 层 CVE 泛滥：每次扫描都报 8~15 条 HIGH/CRITICAL，集中在 openssl、zlib、glibc，很多是上游 6 个月才会出修复版本的老 CVE。开发同学直接说"这跟我的代码没关系，是基础镜像的事"，卡点形同虚设，最后被豁免名单豁免掉了。
2. 语言层依赖疑似漏报：我们有一个内部二方包（自托管 Nexus 发布）里传递依赖了一个老版本的 fastjson，Trivy 扫出来是干净的；但开发同学本地用 trivy fs --root . 扫源码目录能扫到这条 CVE。我怀疑是镜像层里 .m2 没被打进去，或者 Trivy 对 jar 内嵌 jar（fat-jar）的解析有边界。

已尝试的排查：

• 确认镜像内确实存在该 jar：docker exec 进去 jar tf 能看到 fastjson-1.2.83.jar；
• 换 trivy image --scanners vuln,secret,misconfig 全开，OS 层结果不变，语言层依旧干净；
• 本地 trivy fs 扫源码目录能扫到，说明 Trivy 本身能识别这个 CVE；
• 怀疑是镜像里 classpath 打包方式（fat-jar vs 展开目录）影响了 Trivy 的依赖解析。

期望得到的答案形态：

1. slim 基础镜像下，OS 层 CVE 与语言层 CVE 的扫描策略应该分开卡还是合并卡？有没有团队在用"OS 层只看 CRITICAL、语言层看 HIGH 起"的分层阈值？
2. Trivy 对 fat-jar 内嵌 jar 的解析边界是什么？有没有已知的漏报场景或 issue？
3. 有没有人把"基础镜像 CVE 豁免清单"做成 CI 里可审计的配置（而不是硬编码豁免名单）？

谢谢，欢迎贴你们的 trivy 命令与豁免策略。