SCA 依赖漏洞扫描作为发布卡点，如何拦住高危又不天天误伤阻塞发布？

背景：我负责一套 8 节点的水平扩展 Spring Boot 3.1 服务，Maven 多模块，依赖里混着不少内部二方包（自托管 Nexus），走 CI/CD 发布。安全团队要求"上线前 SCA 卡点"，但过去半年这个卡点基本被掏空，我想系统性重构一下。

现象与卡点： 1）用 OWASP dependency-check + Trivy 扫，传递依赖里堆出一堆 CVE，其中不少是"声明了但代码根本没调用"的库，直接修不动，只能绕； 2）内部二方包没有 SBOM，dependency-check 基本扫不到，只能靠包名/坐标匹配，误报和漏报都很多； 3）每次发布都被新扫出的中危 CVE 卡住，开发同学强烈抵触，最后靠"白名单豁免"放行，豁免清单越堆越长，等于卡点失效； 4）真正的高危 CVE 修复往往要升级父级大版本，回归成本高，大家不敢升，拖成遗留债务。

已尝试的排查与结果：

• 白名单豁免：结果是豁免项从 12 条涨到 60+ 条，卡点形同虚设；
• 只卡 critical/high：但相当一部分 high 是"声明未调用"的误报，开发仍觉得冤枉；
• 直接升级依赖：传递依赖被其它库锁死，升了 A 崩了 B，回滚了事。

期望得到的答案形态：

• 一套可落地的分级卡点策略：critical/high/medium 分别怎么处理，豁免机制怎么设计才不会被掏空（比如有效期、责任人、复审）；
• 对"声明未调用"的传递依赖 CVE，业内怎么判定是否真正可利用（reachability / 调用链分析，Snyk、Dependabot 这类是怎么做的）？
• 内部二方包没有 SBOM 的破局办法：如何生成与收集 SBOM（CycloneDX / SPDX），怎么在 CI 里聚合多模块 + 私有仓库的依赖清单；
• 高危 CVE 必须升级大版本时，如何控制回归风险（影子流量、canary、契约测试）；
• 工具选型：dependency-check vs Trivy vs Snyk，在 Maven 多模块 + 私有 Nexus 场景下的实测差异与踩坑。

欢迎有具体落地案例的同学贴出你们的卡点规则与豁免治理流程，谢谢。