Trivy 扫描 Azure Linux（CBL-Mariner）系统软件包：SBOM、漏洞与 License 支持全景指南

Azure Linux（3.0 起由 CBL-Mariner 更名而来）是微软为容器与云基础设施打造的精简 Linux 发行版，广泛用于 Azure 上的基础镜像与 VM 场景。本指南以 Trivy 官方 OS 支持文档为骨架，系统梳理 Trivy 对 Azure Linux 1.0 / 2.0 / 3.0（含 Distroless）在 SBOM 生成、漏洞检测与 License 识别三个维度上的能力边界，并结合仓库中 pkg/detector/ospkg/azure、OS 识别与 RPM 分析等源码实现，帮助读者在容器镜像与虚拟机安全扫描实践中准确选型、正确解读结果。

Azure Linux 与 CBL-Mariner 的背景说明

Azure Linux 的前身是 CBL-Mariner（Common Base Linux Mariner），从 3.0 版本起官方更名为 Azure Linux。这一更名同时反映在 Trivy 的类型模型中：

• 在 pkg/fanal/types/const.go 中，Trivy 定义了两种 OS 类型：Azure = "azurelinux" 与 CBLMariner = "cbl-mariner"；
• 在 pkg/fanal/analyzer/os/release/release.go 中，os-release 解析器会把 ID=azurelinux 映射为 Azure，把 ID=mariner 映射为 CBLMariner。

也就是说，Trivy 内部通过 /etc/os-release 中 ID 字段的取值自动区分新旧命名，用户无需手工指定即可对两类镜像/系统正确识别与扫描。

支持矩阵总览

不同扫描器的版本支持情况

针对 OS 软件包，Trivy 对 Azure Linux 各主要版本支持的扫描器如下：

版本	SBOM	漏洞（Vulnerability）	License
1.0	✔	✔	✔
1.0（Distroless）	✔	✔
2.0	✔	✔	✔
2.0（Distroless）	✔	✔
3.0	✔	✔	✔
3.0（Distroless）	✔	✔

可见 SBOM 与漏洞检测在全部版本（含 Distroless）上均受支持；License 检测仅在非 Distroless 的标准镜像上可用，Distroless 镜像不提供（详见下文 License 一节）。

可扫描目标

版本	容器镜像	虚拟机	架构
1.0	✔	✔	amd64、arm64
2.0	✔	✔	amd64、arm64
3.0	✔	✔	amd64、arm64

从 docs/guide/coverage/os/azure.md 可以确认：1.0–3.0 均同时支持容器镜像与虚拟机两类目标，且覆盖 amd64 与 arm64 两种主流架构。

功能特性支持情况

功能	是否支持
检测未修复漏洞（unfixed vulnerabilities）	✓
依赖图（Dependency graph）	✓
生命周期终止感知（End of life awareness）	–

未修复漏洞检测与依赖图（即报告结果中展示"易受攻击依赖的来源/路径"）均可用；而 EOL 感知不支持。从源码看，这与 azure.go 中 IsSupportedVersion 的实现一致——由于微软官方尚未公开 Azure Linux 的 EOL 数据，该函数目前无条件返回 true：

// IsSupportedVersion checks if the version is supported.
func (s *Scanner) IsSupportedVersion(_ context.Context, _ ftypes.OSType, _ string) bool {
	// EOL is not in public at the moment.
	return true
}

SBOM：如何枚举 Azure Linux 软件包

Trivy 对 Azure Linux 的 SBOM 支持，本质上是枚举其 RPM 软件包数据库。官方文档明确指出，Trivy 会检测通过 tdnf、dnf 与 yum 等包管理器安装的软件包——这三种包管理器在 Azure Linux 体系中分别面向不同版本/场景：tdnf 是 CBL-Mariner/Azure Linux 内置的 DNF 衍生包管理器，dnf/yum 则兼容传统的 RPM 系工具链。

在仓库中，这一过程由 pkg/fanal/analyzer/pkg/rpm 下的 RPM 分析器完成，其通过解析 RPM 数据库（rpmqa）与 RPM 头信息得到包名、版本、发布号（release）、架构、Source 包名（SrcName/SrcVersion）以及 License 等元数据，为后续漏洞比对与 License 识别提供统一的软件包清单。

漏洞检测

Azure Linux 拥有微软官方维护的独立安全公告体系。与 Debian/Ubuntu 等使用上游发行版公告不同，Trivy 在扫描 Azure Linux 时使用微软官方为 Azure Linux 发布的安全公告数据（即 Azure Linux OVAL），而不是套用通用 CVE 数据库。

数据源

Trivy 的漏洞数据库构建自微软官方维护的 Azure Linux Vulnerability Data 仓库，其 OVAL 数据在 trivy-db 中由 vulnsrc/azure 模块消费并入库。该扫描器的数据源定义与各发行版安全数据源的汇总清单可参见 docs/guide/scanner/vulnerability.md。

值得留意的是，同一套扫描器实现同时服务于新旧两种命名：从 azure.go 可以看到，工厂函数分别构造了面向 Azure（新名）与 Mariner（旧名）两个分发（distribution）的扫描器，二者共享同一套漏洞比对逻辑：

func NewAzureScanner() *Scanner {
	return newScanner(azure.Azure)
}

func NewMarinerScanner() *Scanner {
	return newScanner(azure.Mariner)
}

而 pkg/detector/ospkg/detect.go 中则完成了 OS 类型到扫描器的注册映射：

ftypes.Azure:              azure.NewAzureScanner(),
ftypes.CBLMariner:         azure.NewMarinerScanner(),

检测流程与固定版本（Fixed Version）

Azure Linux 的 OVAL 数据中仅包含源软件包（source package）名称，因此 Trivy 在比对时必须使用 RPM 包解析出的 SrcName 作为查询键，而不是二进制的包名。核心检测逻辑集中在 azure.go 的 Detect 方法中，要点如下：

1. OS 版本归一化：先将 os-release 中如 1.0.20210127 这样的完整版本串通过 osver.Minor 规约为小版本号 1.0，再作为发行版版本（release）参与公告查询。
2. 以源包名查公告：对每个软件包以 pkg.SrcName 在对应版本的安全公告中查询 advisories。
3. 版本比对：使用 github.com/knqyf263/go-rpm-version 提供的 RPM 版本比较语义：
   • 若公告中 FixedVersion 为空，说明该漏洞尚未被修复，直接记录为无修复版本（unpatched）的漏洞；
   • 否则将已安装的源包版本与公告中的修复版本比较，当 sourceVersion.LessThan(fixedVersion) 时判定为受影响，并把 FixedVersion 一并写入检测结果。

也就是说，"已修复版本"完全取自 Azure Linux OVAL 中声明的修复版本；这类比对按 RPM 版本规则处理 Epoch/Release 等细节，而非简单的字符串比较。单元测试 azure_test.go 中提供了可验证的样例：安装版本 php-8.3.6-1.azl3、SrcName=php 的包，在 OVAL 声明修复版本 8.3.8-1.azl3 时，最终被检出为 CVE-2024-2408，且 InstalledVersion=8.3.6-1.azl3、FixedVersion=8.3.8-1.azl3。

严重级别（Severity）

Trivy 依据 [Azure Linux OVAL] 数据中为每条公告标注的严重级别来计算漏洞的严重性（即报告里呈现的 CRITICAL / HIGH / MEDIUM / LOW 等）。因此，对于 Azure Linux 而言，严重性口径与微软官方公告保持一致，扫描结果可以直接与 Azure 侧的修复指导对齐。

漏洞状态（Status）

Trivy 对不同 OS 的漏洞状态（Vulnerability Status）支持度不同。对 Azure Linux，官方文档确认当前仅支持以下两种状态，其余状态均不受支持：

状态	是否支持
Fixed（已修复）	✓
Affected（受影响）	✓
Under Investigation（调查中）
Will Not Fix（不修复）
Fix Deferred（推迟修复）
End of Life（已终止支持）

这一状态体系与"按状态过滤"功能直接相关：用户可以在报告中基于上述状态进行筛选，相关用法与过滤规则可参考 docs/guide/configuration/filtering.md。

License 检测

Trivy 对 Azure Linux 的 License 识别方式与 Ubuntu 等发行版不同——它不依赖逐文件的版权扫描，而是直接检查 RPM 软件包的元数据（即每个包自身声明的 License 字段）。该流程与 SBOM 共用 RPM 分析产物：在 azure_test.go 的软件包样例中可以看到，每个被测包都携带 Licenses 字段（如 php 包声明 Php、bind-utils 包声明 ISC），Trivy 正是通过聚合这些 RPM 元数据来完成 License 统计与报告。

注意：Azure Linux Distroless 镜像不支持 License 检测。Distroless 镜像因精简掉了常规包管理运行时信息，无法可靠获取 RPM 元数据，因此即使 SBOM 与漏洞检测可用，License 扫描结果在 Distroless 镜像上也不可用。

使用建议与注意事项

综合官方文档与源码实现，面向 Azure Linux 使用 Trivy 时建议注意以下几点：

• 无需区分新旧命名：无论是 azurelinux 还是 mariner 的 os-release，Trivy 都能通过 pkg/fanal/analyzer/os/release/release.go 自动识别并走对应的 Azure Linux 扫描器，命令与配置无需手工指定 OS 类型。
• 查询键为源包名：由于 Azure Linux OVAL 只索引源软件包，扫描结果的对齐天然发生在源包层面，二进制的 RPM 包会被映射回其源包后再做比对——这与部分依赖二进制包名的发行版存在差异，解读报告时无需担心包名不一致是 bug。
• 修复进度以微软公告为准：固定版本与严重级别均来自 Azure Linux OVAL，若某 CVE 在微软侧尚未分配修复版本，Trivy 会将其标记为未修复漏洞而不是直接过滤掉，适合用于持续跟踪上游补丁进度。
• EOL 数据暂缺：由于官方尚未公开 EOL 时间表，Trivy 不会对已终止支持的 Azure Linux 版本给出 EOL 提示，企业若维护较老版本需自行关注官方支持周期。
• Distroless 镜像的 License 缺口：在使用 Azure Linux Distroless 作为基础镜像时，SBOM 与漏洞检测可用，但 License 合规结果会缺失，License 类合规扫描请改用标准镜像。

总结

Azure Linux（CBL-Mariner）是 Trivy 完整支持的一类 RPM 系发行版：1.0–3.0 全版本覆盖容器镜像与虚拟机、amd64 与 arm64 架构，SBOM 与漏洞检测在标准与 Distroless 镜像上均可用，License 检测则依赖 RPM 元数据、对标准镜像可用。漏洞检测以微软官方 Azure Linux OVAL 为唯一事实来源，支持 Fixed 与 Affected 两类状态、支持未修复漏洞检出，但暂无 EOL 感知能力。掌握这些边界，可以帮助你在 Azure 容器与 VM 的安全扫描中准确判断结果语义，并对齐微软官方公告推进修复闭环。