前言
随着软件供应链攻击的频发，SBOM（软件物料清单）已成为现代安全防御的基石。近期 Phoronix 报道的 Linux 内核内置 SPDX SBOM 生成工具，不仅提升了合规性自动化水平，更标志着 Linux 社区从"代码开源"向"构建过程透明化"迈出的关键一步。
一、 核心概念：SBOM 与 SPDX 的协作
在深入工具之前，我们需要明确这两个高频出现的术语：
-
SBOM (Software Bill of Materials)：软件物料清单。可以形象地比喻为软件的"配料表"。对于内核而言，它详细列出了最终二进制镜像中包含的所有源码文件、版本信息及依赖关系。
-
SPDX (Software Package Data Exchange)：由 Linux 基金会主导的国际标准。它为 SBOM 提供了一种统一的机器可读语言，确保不同的安全扫描工具能够无缝解析这些"配料表"。
二、 三位一体：全维度的文档生成架构
该工具最显著的技术特点在于它不是生成单一的列表，而是产出一套"三位一体"的 JSON 文档。这种结构通过 Kbuild 系统的构建轨迹（.cmd文件）将源码与产物紧密锁死：
-
Source SBOM（源码清单）：描述内核源码树中被激活的源文件，包含路径、许可标识（如 GPL-2.0）及哈希值。
-
Build SBOM（构建映射清单）：关键桥梁。记录了特定的
.c文件通过哪条编译器指令变成了哪个.o文件，确保了构建过程的可追溯性。 -
Output SBOM（产物清单）：描述最终交付给用户的二进制文件，涵盖
vmlinuz镜像、头文件以及所有已编译的内核驱动模块（.ko）。
三、 深度解析 VEX：拒绝"漏洞误报"的聪明机制
在 SPDX 3.0.1 标准中，最引人注目的功能是引入了VEX (Vulnerability Exploitability eXchange，漏洞利用交换)。
VEX 解决了什么问题？传统扫描工具只要看到源码中有已知漏洞（CVE）就会报警。但 Linux 内核极其复杂，很多时候**"有漏洞代码"并不等于"受影响"**。VEX 赋予了内核维护者"自证清白"的能力：
-
状态标定：维护者可以将漏洞标定为Not Affected（不受影响）。
-
理由溯源：VEX 允许提供理由，例如
code_not_compiled（代码未编译）。 -
实际应用：如果你的内核配置（
.config）中关闭了某个有漏洞的驱动，生成的 SBOM 就会通过 VEX 告知审计工具："虽然源码里有这个漏洞，但由于没编译进去，当前镜像安全，请忽略报警。"
四、 开发者指南：如何在本地编译中试用
开发者目前可以通过以下流程在实验性环境中体验：
-
获取补丁：从 LKML 下载
kbuild: add SPDX SBOM generation系列补丁并应用。 -
配置开启：在内核配置中启用
CONFIG_SBOM=y。 -
执行编译：执行
make -j$(nproc)。构建系统会记录下每一个编译步骤的"足迹"。 -
生成文档：编译完成后，运行
make sbom。工具会回溯依赖链，产出上述三位一体的 JSON 文档及 VEX 声明。
五、 核心协议：为什么选择 SPDX 3.0.1？
该工具率先采用了最新的SPDX 3.0.1标准，其优势在于：
-
从列表到图谱：支持通过Relationship定义复杂的逻辑关联（如：A文件"被链接入"B模块）。
-
原生支持 VEX：将安全声明（Security Profile）与软件清单深度耦合，极大降低了企业运维的时间成本。
{#section path-to-node="27"}
总结
将 SBOM 生成工具内置于scripts/目录，意味着未来的 Linux 内核将拥有"自带配料表"和"自检报告"的能力。这不仅方便了合规审计，也为自动化漏洞扫描提供了最权威的一手数据。
LeisureLinux 频道贴士：理解 VEX 的前提是理解 Linux 的条件编译。在LeisureLinux的视频中多次提到过
obj-$(CONFIG_XXX)这种语法，这正是 VEX 能够精准判断漏洞是否"受影响"的最底层逻辑——只要CONFIG没开，漏洞就进不去生成的二进制文件。
