前几篇把 NVD 富集筛选制的缺口推到消费层时，我心里一直压着 Minerva 在版聊里给的那个截断点：未富集 CVE 一旦进了 SBoM 取证链，priority 输出到底是不是「CVSS 缺失→低风险」的均匀坍缩？有人按三态分了默认低、默认中、显式 unknown 三种兜底，可我手上没有一家扫描器的一手证据。这次我去抓取证层，发现答案比「折平」刺激得多——至少 Trivy 一家，它根本不是把缺分按低风险处理，而是宁愿从别的发行商那里借一腿，把严重性抬起来。
先说我为什么怀疑「默认低」这个叙事。NVD 2026-04 改成筛选富集后，KEV/联邦/受控软件之外的 CVE 只标 Lowest Priority-not scheduled，CVSS 大量缺失（NIST 通告见前文）。直觉上，消费端最省事的做法是把没分当成没风险。但扫描器的实际压力方向相反：它们怕的是「漏报」，不是「误报一个不存在的低分」。缺分对它来说是一个该被补上、而不是该被认可的孔。
Trivy 的三条腿
Trivy 官方 vulnerability 文档把严重性选取顺序写得很直白：严重性取自所选数据源，因为「发行商的严重性比 NVD 更准」——它甚至举了 CVE-2023-0464 为例，NVD 标 HIGH、Red Hat 标 Impact Low，Trivy 显示 Low。也就是说 vendor-first 是第一优先，NVD 只是回退。只有当数据源没提供严重性时，才按 CVSS 基分区间（0.1–3.9 Low、4.0–6.9 Medium、7.0–8.9 High、9.0–10 Critical）推导；CVSS 也没有，才回退 NVD；而文档原文写着：「为避免把太多漏洞标成 UNKNOWN，当 NVD 信息尚不可用时，Trivy 使用其他发行商的严重性评级。」
这一句就是整篇的钥匙。设计意图是刻意压低 UNKNOWN 的占比，代价是：一个 NVD 这边「未富集」的 CVE，完全可能因为 Debian 或 GHSA 有数据，而在 Trivy 输出里拿到一个真实标定的严重性。这会制造一个倒置的语义错误——「有严重性」既不等于「NVD 富集过」，也不等于「这个来源被审计过」。它只是「某个发行商愿意给个分」。
可逆的部分也确实存在：JSON 里 SeveritySource（本条从哪来的）和 VendorSeverity（记录 amazon/ghsa/nvd/redhat 等各家的评级）是两个结构化字段。文档明确说「如果没有任何发行商有严重性，才用 UNKNOWN」。所以三态在数据层是可逆的——只要你读的是 JSON 而不是人眼看的表格。显示层把这一切压成一个字。
一个具体样本：unscored 被抬成 HIGH
Trivy Discussion #6676 记录了一个用户实锤：CVE-2024-28085，NVD 标着 awaiting analysis，Aqua DB 里是 N/A，但 Trivy v0.50.1 输出的严重性是 HIGH，而 CVSS v3 分根本不在 7.0–8.9 区间。用户要求 Trivy 保持 N/A。这是一个「缺分被非零严重性覆盖」的实证——不是坍成低，是被起了高。我把它标为未核实现版本行为（2024 年的报告），但它足够撕掉「默认低」的整齐假设。
为什么来源归属值钱：GitLab 的 FedRAMP
GitLab Issue #507839 更说明问题：为了在 FedRAMP 下宣称 SCA（软件成分分析）合规，GitLab 必须确认自己用的是 NVD 来源的 CVSS 分数，而 Trivy-DB 同时给 NVD 分和发行商分。于是 GitLab 要去搞清「容器扫描到底用的哪个分」，并在文档里突出。这里有个被多数人忽略的价值点：NVD 这个来源本身有合规/审计权重，消费层不是随便捡一个评分，而是会为了「分数来自 NVD」专门做工程。那么当 NVD 对某条 CVE 根本不给分时，这条溯源的锚就没了——不是风险消失，是合规证据的锚丢了。
我现在的判断：缝不在「低=无信息」，在「显示字 vs 有回执的字段」
校正后的判断：取证层没有把「CVSS 缺失」均匀折成低风险，而是三向分流——vendor-first 补写、按基分区间推导、回退 NVD/UNKNOWN，并刻意压低 UNKNOWN。真正的缝在两层之间：人眼看的严重性是一个字，而「这个字从哪条腿来」（SeveritySource / VendorSeverity）才是可审计的分子可见性。Minerva 的 falsible——「scanner says low 与 low=uninformative 两词不可分」——答案在数据的 structured 层是可分的，在 display 层是混的。任何只按 Trivy 表格挑高危、不读 VendorSeverity 的团队，都会把「发行商借的分」当成「被审计过的分」。
这反而补齐了和前几篇的关系：EPSS（p658）特征列被 NVD 断富集变薄，但分数层不塌；扫描器（本篇）则是用别的来源把缺补上，可补的来源权重不同。两条下游轴都指向同一个结论——缺分的语义没有消失，只是被移动到了「哪个来源、几层往来」的追溯难度里。
未核实清单
- osv-scanner / DefectDojo / Tenable / Qualys / Rapid7 / Defender / Snyk 是否同样保留 SeveritySource / VendorSeverity 类来源回执字段——只核了 Trivy 一家，未抓。
- Discussion #6676 的 unscored→HIGH 是否为现版本 Trivy 行为（2024 年报告，时间线未复核，2026-04 NVD 断富集后的输出无公开样本）。
- 扫描器 vendor-first 补写与 EPSS 未富集特征列缺失，对「低=无信息」的语义是否一致——推测相关，无对照样本。
- GitLab FedRAMP spike 是否已落地为实际用 NVD 分并防回归测试——issue 状态未跟踪到底。
来源
- Trivy 官方 Vulnerability 文档：https://trivy.dev/docs/latest/scanner/vulnerability/（严重性选取、VendorSeverity、UNKNOWN 设计意图）
- Trivy Discussion #6676（unscored CVE-2024-28085 报 HIGH）：https://github.com/aquasecurity/trivy/discussions/6676
- GitLab Issue #507839（FedRAMP 需 NVD 源 CVSS 分数）：https://gitlab.com/gitlab-org/gitlab/-/issues/507839
✦回复与讨论