Trivy 对 Debian GNU/Linux 的漏洞扫描支持详解：SBOM、安全通告数据源与许可证检测

Trivy 对 Debian 系操作系统（apt/dpkg 包管理体系）提供了从 SBOM 清单生成、CVE 漏洞检测到软件许可证识别的完整扫描链路。本文围绕 docs/guide/coverage/os/debian.md 展开，梳理 Debian 支持的扫描器矩阵、漏洞检测所依赖的安全通告数据源（Security Tracker）与严重性判定逻辑、以及基于 copyright 文件的许可证探测机制，并结合仓库源码说明这些能力背后的具体实现。读完你将对"Trivy 如何处理一个 Debian/Ubuntu 容器"有端到端的认知，并能正确解读结果中 fixed version、severity 与 status 字段的由来。

支持范围总览

Debian 是 Trivy 覆盖率文档（docs/guide/coverage/os/index.md）中明确列出的目标操作系统，其包管理器为 apt/dpkg，当前支持 Debian 7、8、9、10、11、12 等发行版本，对应的 Ubuntu 也被标记为"支持 Canonical 官方维护的全部版本"。

针对 Debian 的 OS 包（操作系统级软件包），Trivy 提供三类扫描器：

Scanner	支持情况
SBOM	✓
Vulnerability	✓
License	✓

也就是说，用 Trivy 扫描一个 Debian 镜像或文件系统时，--scanners sbom、--scanners vuln 与 --scanners license 均可用，OS 包层面即可同时完成软件物料清单、已知漏洞与许可证三种分析。

针对漏洞扫描这一能力，Debian 还额外支持如下特性：

Feature	支持情况
未修复漏洞（Unfixed vulnerabilities）	✓
依赖图（Dependency graph）	✓
生命周期结束感知（End of life awareness）	✓

其中依赖图能力对应报告阶段的 --show-suppressed/依赖来源展示，参见 docs/guide/configuration/reporting.md；生命周期结束感知则依赖源码中维护的 Debian EOL 时间表，详见下文分析。

SBOM：能检测哪些"已安装"软件包

在 SBOM 层面，Trivy 只能识别通过包管理器（apt/dpkg）正规安装的软件包。这背后的实现位于 pkg/fanal/analyzer/pkg/dpkg/dpkg.go：分析器通过读取 dpkg 的元数据（如 var/lib/dpkg/status、var/lib/dpkg/info/ 目录下的文件），并以正则捕获源码包名与版本（dpkgSrcCaptureRegexp）来重建已安装软件包清单。

文档特别提醒了一个重要例外场景：

• Go 二进制、JAR 文件等由语言包管理器（而非 apt）安装的内容，不属于 dpkg 的管辖范围，会被各自的 language scanner 单独处理；
• 通过 make 手工编译的自定义二进制、通过 curl 下载安装的工具，由于没有经过 dpkg 登记，通常不会被 Debian 的 SBOM 检测到。

也就是说，扫描一个"包含手工编译产物"的 Debian 镜像时，SBOM 里缺少某些可执行文件是符合预期的，它们应由仓库/文件系统层的扫描来覆盖。

操作系统识别

在进入 dpkg 解析之前，Trivy 需要先判定目标属于 Debian 系。OS 识别分析器位于 pkg/fanal/analyzer/os/debian/debian.go，它只要求存在 etc/debian_version 这一文件（requiredFiles），读取其首行内容作为 OS 版本号并标记 family 为 Debian。这一设计也让 Google Distroless、Bitnami 等基于 apt/dpkg 的容器镜像天然被识别为 Debian 家族进行扫描（参见 docs/guide/coverage/os/google-distroless.md）。

Vulnerability：以 Debian 官方安全通告为准

漏洞检测不使用通用 CVE 库直接比对，而是优先消费 Debian 官方发布的安全通告（Security Advisory）。文档明确指出：

Debian offers its own security advisories, and these are utilized when scanning Debian for vulnerabilities.

其完整数据源说明见 docs/guide/scanner/vulnerability.md 中的 Data Sources 小节——Debian 对应的数据源是 Security Bug Tracker 与 OVAL（Debian 官方维护的安全数据）。

从源码调用链可以验证这一点：Trivy 的 Debian 检测器 pkg/detector/ospkg/debian/debian.go 在 NewScanner() 中直接构造了 debian.NewVulnSrc()（来自 trivy-db 中的 Debian vulnsrc 数据源），检测时以 Release（OS 主版本号）+ PkgName（源码包名）为参数查询 advisories（pkg/detector/ospkg/debian/debian.go 中 Detect 的 Get 调用）。随后通过 go-deb-version 库对"已安装版本"与"修复版本"做 Debian 版本语义的比较（sourceVersion.LessThan(fixedVersion)），命中即输出 DetectedVulnerability，其中包含 FixedVersion、Status、DataSource、SeveritySource 等字段。

Fixed Version：为什么与 NVD 的修复版本不同

Debian 的"修复版本"指的是 Debian 自己打的补丁所对应的版本，而不是上游软件项目的修复版本。文档给出的典型示例是 CVE-2023-3269：

• Debian 12（bookworm）的修复版本在 Security Tracker 中被记录为 6.1.37-1；
• 该补丁由安全通告 DSA-5448-1 提供；
• 而上游的修复版本是 6.5，两者完全不同。

关键提示在于：NVD 通常只登记上游版本信息。如果你拿 Debian 的漏洞报告与 NVD 对照，发现 fixed version 不一致，请勿困惑——Trivy 遵循 Debian 侧的信息，因为运行在 Debian 上的是 Debian 修复后的内核/软件，而非上游原版。这正体现了发行版安全通告扫描"以发行版补丁状态为准"的设计哲学。

从源码角度，该检测器对 OS 版本号做了一次 osver.Major(osVer) 归一化处理（如把 12.5 归并为 12），然后以该主版本去查询对应 release 的 advisories，确保修复版本按具体 Debian 大版本区分。

Severity：Urgency 优先于 NVD 评级

Trivy 计算 Debian 漏洞严重性时，以 Security Tracker 中的 "Urgency"（紧急度） 指标为准；如果 Debian 没有提供 Urgency，才回退到 NVD 的严重性。

文档示例 CVE-2019-15052 极好地说明了这一差异：

• 该漏洞在 NVD 中被评级为 "Critical"；
• 但 Debian 在 Security Tracker 中将其 Urgency 标记为 "Low"；
• 因此 Trivy 会把它展示为 "Low"。

这是因为从 Debian 发行版视角看，该漏洞的实际可利用性与影响被发行版的补丁/配置策略所缓解。实现上（pkg/detector/ospkg/debian/debian.go 的 Detect 逻辑）：当 advisory 携带的 severity 不是 SeverityUnknown 时，Trivy 会写入 SeveritySource = vulnerability.Debian，并使用 Debian 给出的 severity 覆盖通用数据库中的值——这也是为什么 JSON 报告中会出现 "SeveritySource": "debian" 字段（见 docs/guide/scanner/vulnerability.md）。

Status：Debian 支持的漏洞状态集合

漏洞状态用于区分"该漏洞在目标发行版中的处置阶段"。Debian 支持的[漏洞状态]见 docs/guide/configuration/filtering.md（该文档按 status 过滤漏洞），具体支持矩阵如下：

Status	支持情况
Fixed（已修复）	✓
Affected（受影响）	✓
Under Investigation（调查中）
Will Not Fix（不会修复）
Fix Deferred（修复延后）	✓
End of Life（已停止维护）	✓

在代码层面，"修复延后"与"生命周期结束"等状态来自 trivy-db 的 Debian advisories（adv.Status 会被透传到 DetectedVulnerability.Status）。特别地，当 adv.FixedVersion == "" 时，检测器会将其视作未修复漏洞直接上报、不做版本比较——这正是特性表中"Unfixed vulnerabilities"得以支持的原因。

EOL：从源码内置时间表说起

"End of life awareness" 特性对应 pkg/detector/ospkg/debian/debian.go 中的 eolDates 映射表与 IsSupportedVersion 方法。该表内置了从 Debian 1.1（1997 年 EOL）到 Debian 13 的 EOL 日期（例如 Debian 11 → 2026-08-14、Debian 12 → 2028-06-10），并调用 osver.Supported 判断目标版本是否仍在生命周期内；对已 EOL 的版本，Trivy 会在扫描结果中提示其已不再受支持。

License：copyright 文件的两级探测机制

许可证检测的目标文件是每个 Debian 包都会附带的版权声明文件 /usr/share/doc/*/copyright。实现位于 pkg/fanal/analyzer/pkg/dpkg/copyright.go（dpkgLicenseAnalyzer），其 Required 方法用 usr/share/doc/*/copyright 的 path 匹配来确定待分析文件。

解析 copyright 文件时，分析器按行识别两类信息：

1. 机器可读格式：以 License: 开头的行（Debian copyright-format 1.0 规范），其内容会被 normalizeLicense 规范化（例如去掉 (MIT) 括号后缀、去掉 "license" 尾部字样）后拆分为许可证列表；
2. common-licenses 引用模式：凡是行内包含 /usr/share/common-licenses/ 引用（例如 GPL-2+），则用正则捕获其后的许可证标识符。

局限与 --license-full 兜底

文档诚实指出该方法的固有局限：copyright 文件本质上并非机器可读格式，因此很多场景下许可证无法被识别（例如版权文件用自然语言描述了混合许可条款，或仅引用了非标准文本）。针对此类情况，Trivy 提供 --license-full 旗标作为兜底方案：

• 启用后，当基于规则的正则解析没有产出结果时，会将 copyright 文件的内容与已知许可证文本做内容比对/分类，从而尽力识别出许可证（源码中即 licensing.Classify 的 fallback 分支）；
• 该过程需要对文件内容做全文匹配，会显著增加内存占用，因此默认关闭以保证扫描效率；
• 完整模式同样支持 --license-confidence-level 来调节分类置信度阈值（参见 docs/guide/scanner/license.md 中对 --license-full 与置信度参数的用法示例）。

一个直接可用的扫描命令形如：

trivy image --scanners license --license-full debian:12

示例中的完整模式会把未命中正则的版权文件交给已知许可证分类器做内容比对，代价是更高的内存消耗。

小结

围绕 Debian GNU/Linux，Trivy 形成了"OS 识别（读取 etc/debian_version）→ dpkg 包清单重建 → 漏洞比对（Debian Security Tracker/OVAL 通告）→ 许可证解析（/usr/share/doc/*/copyright）"的完整链路，本文依次解释了其扫描器支持矩阵、SBOM 检测边界、漏洞检测中 fixed version/severity/status 的来源差异（Debian 侧信息优先于 NVD），以及 license 检测的两级机制。需要进一步细化时，可继续阅读 docs/guide/coverage/os/ubuntu.md（同属 apt/dpkg 家族的 Ubuntu 支持情况）以及 docs/guide/scanner/license.md 的完整扫描器说明。